jps não retorna saída mesmo quando os processos java estão em execução

Estou tentando depurar alguns problemas com processos java em uma checkbox do Solaris, mas a execução de jps não retorna nenhuma saída. E o jstack dá o erro “Permissão negada”. A checkbox faz parte de um cluster de 3 servidores idênticos, jps e jstack funcionam bem nos outros 2 servidores.

Eu encontrei a seguinte mensagem no fórum de alguém com o mesmo problema, mas sem respostas: http://forums.sun.com/thread.jspa?threadID=5422237

Para esclarecer a execução de bps e grep para java dá todos os processos java corretamente, mas jps não dá nada (anonimizado com ‘programa’ e ‘cliente’ para proteger o culpado):

program @ clientdelivery2 : ~/ -> bps auxww|grep java program 3427 5.5 54.067742726649544 ? S Sep 25 1039:47 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/client/program/tomcat/conf/logging.properties -Xmx6144m -XX:PermSize=128m -XX:MaxPermSize=512m -Djava.endorsed.dirs=/app/client/program/tomcat/endorsed -classpath :/app/client/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/client/program/tomcat -Dcatalina.home=/app/client/program/tomcat -Djava.io.tmpdir=/app/client/program/tomcat/temp org.apache.catalina.startup.Bootstrap start program 29915 0.1 11.915252441467896 ? S 14:55:28 3:59 /usr/jdk/instances/jdk1.6.0_16/bin/amd64/java -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=/app/clientclone/program/tomcat/conf/logging.properties -Xmx2g -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.endorsed.dirs=/app/clientclone/program/tomcat/endorsed -classpath :/app/clientclone/program/tomcat/bin/bootstrap.jar -Dcatalina.base=/app/clientclone/program/tomcat -Dcatalina.home=/app/clientclone/program/tomcat -Djava.io.tmpdir=/app/clientclone/program/tomcat/temp org.apache.catalina.startup.Bootstrap start program 1573 0.0 0.0 4760 1332 pts/5 S 17:05:24 0:00 grep --colour java program @ clientdelivery2 : ~/ -> jps program @ clientdelivery2 : ~/ -> 

Eu perguntei por aí e daqui http://forums.oracle.com/forums/message.jspa?messageID=5408592 Eu tenho que o problema é:

 12460/2: mkdir("/tmp/hsperfdata_program", 0755) Err#13 EACCES [ALL] 

Significado jps está sendo negado o access ao diretório psperfdata.

Alguém se deparou com esse problema e sabe como resolvê-lo?

Acontece que o usuário não tem access ao / tmp por causa de algum problema com a assembly do sistema de arquivos. Isso faz com que os arquivos dentro do hsperfdata_ nunca sejam gravados, mesmo que o usuário tenha access à própria pasta / tmp / hsperfdata_.

Certifique-se de que o programa que você está tentando ‘detectar’ com jps (e jstack, aliás) seja executado sem definir a configuração java.io.tmpdir ou configurá-lo para o padrão do sistema.

Há vários bugs nos locais de diretório temp do Sun Developer Network que não devem ser codificados , Fix for 6938627 interrompe o monitoramento visual quando o -Djava.io.tmpdir e o diretório temporário usam a propriedade java.io.tmpdir que são relevantes aqui.

A história: java Java 6 Update 22 costumava usar um diretório temporário codificado para colocar dados reunidos para uso por jps e jstack. Os programas jps e jstack sabiam onde procurar.

No entanto, como alguém criou um ‘bug’ no Java 6 Update 23, ele ‘corrigiu’ para usar a configuração java.io.tmpdir java runtime. Agora, o padrão é um local específico do sistema, que é o que o código “codificado” era. Mas se você definir a opção ao invocar seu programa java, ele usará isso. Resultado: jps e jstack olham onde esperam e não encontram nada.

A solução é, portanto, garantir que a opção java.io.tmpdir esteja configurada para o padrão do sistema (por exemplo, no Mac:

 > java -Djava.io.tmpdir=$TMPDIR javamain 

)

ao invocar seu programa. Então jps e jstack irão encontrá-lo.

Meu colega Glyn Normington descreve isso em seu blog . Existe aparentemente uma correção no Java 6 Update 25.

tldr: sudo jps trabalhou para mim (por motivos invocados em outras respostas)

Experimentar:

 jps -J-Djava.io.tmpdir=/app/client/program/tomcat/temp 

Você está executando o jps como o mesmo usuário que está executando os processos Java? Mesmo se você executar o jps como root, ele retornará apenas os processos executados por esse usuário (root, neste caso).

Além disso, certifique-se de que seu script de boot não inclua -XX:+PerfDisableSharedMem pois com essa opção a JVM não -XX:+PerfDisableSharedMem nenhuma estatística, tornando o processo invisível para jps e jstat .

Consulte os https://support.datastax.com/hc/en-us/articles/208269876-Java-utilities-such-as-jps-or-jstat-unable-to-monitor-DSE-processes para obter detalhes.