As part of metadata collection, gProfiler collects the output of java -version for profiled Java application. This is doable when the target process is basenamed java - in that case we know that we can execute the same path with -version argument, and get the version.
However, since our process selection for Java processes is based on processes which have libjvm.so loaded (see JavaProfiler._select_processes_to_profile()), we stumble upon Java processes which are other executables loading libjvm.so. One of them is https://commons.apache.org/proper/commons-daemon/jsvc.html for example. These do not necessarily support -version, so we don't do the version check.
Proposed solutions:
As suggested here - try to get the java binary path for the same Java installation, then use java -version from that binary.
Create a whitelist of other basenames and provide specific commandlines to handle them. For example, jsvc per its documentation claims to support jsvc -version, so we can just do that. There might be others with different options. I will update this ticket with the different non-java I see.
As part of metadata collection, gProfiler collects the output of
java -versionfor profiled Java application. This is doable when the target process is basenamedjava- in that case we know that we can execute the same path with-versionargument, and get the version.However, since our process selection for Java processes is based on processes which have
libjvm.soloaded (seeJavaProfiler._select_processes_to_profile()), we stumble upon Java processes which are other executables loadinglibjvm.so. One of them is https://commons.apache.org/proper/commons-daemon/jsvc.html for example. These do not necessarily support-version, so we don't do the version check.Proposed solutions:
javabinary path for the same Java installation, then usejava -versionfrom that binary.jsvc -version, so we can just do that. There might be others with different options. I will update this ticket with the different non-javaI see.Sites to fix