The simple solution is probably not delete those files. :) If this is a long known bug, did you actually open a bug report with any of the OpenJDK contributor organizations and what’s the number?
Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: serviceability-dev <serviceability-dev-boun...@openjdk.java.net> im Auftrag von nijiaben <nijia...@perfma.com> Gesendet: Mittwoch, Juni 19, 2019 7:12 PM An: serviceability-dev; jdk8u-dev; hotspot-runtime-dev Betreff: A Bug about the JVM Attach mechanism Hi, All, There is a bug that has been discovered for a long time, but it has not been fixed. We usually use some shell scripts to clean up the /tmp directory. When we have executed a similar jstack command based on the attach mechanism, it will generate a .java_pidXXX socket file in the /tmp directory. Once this file is clean up, and then will not be attached anymore. The main reason is that once the Attach Listener thread is created, the file of “/tmp/.java_pidXXX” will be created and the markup initialization is complete. If .java_pidXXX is cleaned up, it will not be created anymore and cannot be attached. bool AttachListener::is_init_trigger() { if (init_at_startup() || is_initialized()) { // initialized at startup or already initialized return false; } char fn[PATH_MAX+1]; sprintf(fn, ".attach_pid%d", os::current_process_id()); int ret; struct stat64 st; RESTARTABLE(::stat64(fn, &st), ret); if (ret == -1) { snprintf(fn, sizeof(fn), "%s/.attach_pid%d", os::get_temp_directory(), os::current_process_id()); RESTARTABLE(::stat64(fn, &st), ret); } if (ret == 0) { if (st.st_uid == geteuid()) { init(); // will create Attach Listener Thread return true; } } return false; } This bug has a big impact on troubleshooting some problems. Can it be fixed as soon as possible? Thanks, nijiaben @ PerfMa
