-Djmx
flags crap.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)
at sun.tools.attach.LinuxVirtualMachine.(LinuxVirtualMachine.java:93)
at sun.tools.attach.LinuxAttachProvider.attachVirtualMachine(LinuxAttachProvider.java:46)
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:195)
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/$PID
files. Sure enough, one of my files was owned by the group root
instead of the group of the user (this is because before forking the JVM, I was calling setuid
to 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/$PID
files 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
VirtualMachine
instance corresponds to the current JVM. Insert something in the system properties (System.setProperty(..)
) and then check whether the VirtualMachine
you 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.
Seems like it can still be problematic if the user owning the process has multiple groups. They way I got around the problem was by going into root and using the runuser command.
ReplyDeleterunuser -u <> -g <> ./bin/jpenable
when i then set the -g to the same group of the file in hsperfdata_$PID it finally worked.