…or why java is running fine, but jps doesn’t show it…
A framework on a live system threw errors in a subdirectory of /tmp/hsperfdata_$user/... after which the /tmp/-space got full.
Thinking “ah, only temp data, let’s just remove it“, I removed all of /tmp/hsperfdata_$user , only to be a little amazed a short while later… Suddenly, jps did not show any data!
Gladly, there is stackoverflow with the root cause: jps uses /tmp/hsperfdata_$user to know what java processes are running. The check, start and stop scripts for the application use jps to check whether the application is already running, started correctly, stopped at all.
The solution to make the scripts work again turned out to require restarting all java-applications, with in between a stop and start having to remove the hsperfdata-$user directory first.
So, temporary as it is,
hsperfdata_$usermay be required during the entire runtime of your application, lesson learned.
A bit of background
jps is a commandline tool in the bin-directory of the jdk. It shows all running javaprocesses, with a pid and naming the main class that is started. jps -v shows commandline parameters. Apparently it uses data in /tmp/hsperfdata_*, so it works without having to connect to a running jvm. The directory contains a file for every running java process. It is a binary file, and as far as I can see it is updated in realtime with performance-related data.
Restart is needed to recreate the pid-related file after it is deleted. Why I had to delete the entire directory in between stop and start I did not find out yet.
Quite possibly other java utilities such as jstat monitor these files for changes. That makes sense: connecting to a running jvm impacts its runtime, monitoring a file that is updated anyway (and is of a fixed size apparently) is cheap and independent of the running jvm.
