Hi,
On 19/06/2019 2:26 am, nijiaben wrote:
Hi, All,
There is a bug that has been discovered for a long time, but it has not
been fixed.
Can you provide a bug number for this?
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.
Once we have attached and created the attach thread we don't need to
perform that initialization handshake because the attach thread exists
and will process any subsequent commands.
David
-----
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
