It worked like a charm, except when run as root. As root, it would instead fail most of the time (but not always!) with this perfectly intelligible exception:
java.io.IOException: well-known file is not secureI Googled that to find it was bug #6649594, but the bug report was completely unhelpful. It mentions a race condition but doesn't explain what the race condition is or how to work around it. Awesome.
at sun.tools.attach.LinuxVirtualMachine.checkPermissions(Native Method)
So, Google Code Search to the rescue! This exception is thrown by
Java_sun_tools_attach_LinuxVirtualMachine_checkPermissions, which is checking that the permissions and mode of a so-called "well-known file" match that of the running JVM. I couldn't trace the code to the location that produces the path, as it's the usual Java-style code with a bazillion layers of abstractions and indirections, but I'm pretty certain this is due to the
/tmp/hsperfdata_$USER/$PIDfiles. Sure enough, one of my files was owned by the group
rootinstead of the group of the user (this is because before forking the JVM, I was calling
setuidto drop the privileges, but I forgot to call
setgid). Fixing the permissions on the file solved the error.
So if you too are scratching your head over this mysterious "well-known file", make sure the permissions on all the
/tmp/hsperfdata_$USER/$PIDfiles are consistent.
The jLOL of the day: it's impossible, in Java, to portably find the PID of the current JVM. So when iterating on all the VMs running on the localhost, here's a workaround to detect whether a
VirtualMachineinstance corresponds to the current JVM. Insert something in the system properties (
System.setProperty(..)) and then check whether the
VirtualMachineyou have at hand has this property. There's a bug filed in — I kid you not — 1999 about this: Bug #4244896 with a whopping 109 votes for it. The bug is in state "Fix Understood", I guess I'm too dumb to understand the fix.