jcmd example java debugging solaris

java - example - jstack



jps no devuelve ninguna salida, incluso cuando los procesos java se están ejecutando (6)

Estoy intentando depurar algunos problemas con los procesos java en un cuadro de Solaris, pero la ejecución de jps no devuelve ningún resultado. Y jstack da el error ''Permiso denegado''. La caja es parte de un grupo de 3 servidores idénticos, jps y jstack funcionan bien en los otros 2 servidores.

Encontré la siguiente publicación en el foro de alguien con el mismo problema pero sin respuestas: http://forums.sun.com/thread.jspa?threadID=5422237

Para aclarar la ejecución de bps y grep para java se obtienen todos los procesos de java correctamente, pero jps no da nada (anonimizado con ''programa'' y ''cliente'' para proteger a los culpables):

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 : ~/ ->

Pregunté por aquí y desde aquí http://forums.oracle.com/forums/message.jspa?messageID=5408592 Tengo el problema:

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

Lo que significa que a jps se le está negando el acceso al directorio psperfdata.

¿Alguien se ha topado con este problema y sabe cómo resolverlo?

¿Está ejecutando jps como el mismo usuario que ejecuta los procesos de Java? Incluso si ejecuta jps como root, solo devolverá los procesos ejecutados por ese usuario (root, en este caso).

Asegúrese de que el programa que está intentando ''detectar'' con jps (y jstack, por cierto) se ejecute sin establecer la configuración java.io.tmpdir , o configurarlo en el valor predeterminado del sistema.

Hay una serie de errores en las ubicaciones temporales de Sun Developer Network que no deben estar codificadas , la Corrección para 6938627 interrumpe la supervisión de visualvm cuando -Djava.io.tmpdir y Make directory directory usan la propiedad java.io.tmpdir que son relevantes aquí.

La historia: Java 6 Update 22 de Java solía usar un directorio temporal codificado para colocar los datos recopilados para ser usados ​​por jps y jstack. Los programas jps y jstack sabían dónde mirar.

Sin embargo, debido a que alguien provocó un ''error'' en Java 6 Update 23, lo ''arreglaron'' para usar la configuración de tiempo de ejecución java.io.tmpdir java en su lugar. Ahora, esto se establece de forma predeterminada en una ubicación específica del sistema, que es la que está "codificada". Pero si configura la opción cuando invoca su programa java, entonces usará eso en su lugar. Resultado: jps y jstack miran donde esperan que esté y no encuentran nada.

Por lo tanto, la solución es garantizar que la opción java.io.tmpdir esté configurada en el valor predeterminado del sistema (por ejemplo, en Mac:

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

)

Al invocar tu programa. Entonces jps y jstack lo encontrarán.

Mi colega Glyn Normington describe esto en su blog . Aparentemente hay una solución en Java 6 Update 25.

Resulta que el usuario no tuvo acceso a / tmp debido a algún problema con el montaje del sistema de archivos. Esto hace que los archivos dentro de hsperfdata_ nunca se escriban, aunque el usuario haya tenido acceso a la carpeta / tmp / hsperfdata_.

Tratar:

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

tldr: sudo jps funcionó para mí (por razones invocadas en otras respuestas)