tutorial thread generate java jstack thread-dump

java - thread - jstack: el proceso de destino no responde



thread dump analyzer (9)

Estoy ejecutando Ubuntu Server Edition y quería tomar un volcado de hilos de Tomcat.

Entonces, primero traté de averiguar qué PID tomcat usa:

$ jps -l 5809 sun.tools.jps.Jps

Pero no está allí?

Entonces, usé la top y descubrí el PID 5730.

Luego llamé a jstack para obtener el volcado de hilo:

$ sudo jstack -l 5730 5730: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding

¿Que esta pasando? :-(

Ya intenté exportar CATALINA_TMPDIR como se describe en Jstack y Jstat dejó de trabajar con la actualización a JDK6u23, pero eso no cambió nada:

$ export CATALINA_TMPDIR=/tmp $ sudo /etc/init.d/tomcat6 restart * Stopping Tomcat servlet engine tomcat6 ...done. * Starting Tomcat servlet engine tomcat6 ...done. $ sudo jstack -l 5934 // new PID after restart 5934: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target process is not responding

Actualizar:

También probé sudo -u tomcat6 jstack -l -F 5730 > threaddumpexceptions2.txt pero solo me da toneladas de excepciones en la consola.

Creo que necesitas ejecutar jstack como el mismo usuario que ejecuta el proceso de Tomcat. Tenga en cuenta también que jps solo devuelve procesos para el usuario actual. Obtendrá el pid para el proceso Tomcat ejecutando jps con sudo o como usuario del proceso Tomcat.

Este informe de error también puede ser útil: https://bugs.launchpad.net/ubuntu/+source/sun-java6/+bug/597098

Encuentro útil usar algo como ''ps -eo pid, user, command | grep java ''para encontrar el comando java real que se está utilizando, luego use el directorio para encontrar el jstack correspondiente, etc.

# ps -eo user,command | grep ''[j]ava'' | cut -d'' '' -f1 someuser /usr/lib/jvm/java/bin/java # /usr/lib/jvm/java/bin/java -version java version "1.6.0_45" Java(TM) SE Runtime Environment (build 1.6.0_45-b06) Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

Entonces es de 64 bits, ejecutándose como ''un usuario''. su a ese usuario y ejecute ejecutar jstack, etc. desde ese mismo directorio. (es decir. / usr / lib / jvm / java / bin / jstack

Útil cuando estás en un servidor con varias instalaciones / implementaciones diferentes de Java.

Esto también funcionó para mí:

sudo -u tomcat6 kill -3 pid

Parece que no pasa nada, pero cuando miras los registros, las pilas están ahí. Se ven como excepciones si no los esperas.

Intenta cambiar al usuario de proceso y luego utiliza jstack:

sudo -u {usuario de proceso} jstack> volcado

Lo hice funcionar haciendo dos cosas:

  1. Se modificó la llamada a: sudo -u tomcat6 jstack -J-d64 -m pid
  2. Se reemplazó OpenJDK con los paquetes Sun-6-jdk y sun-6-jre originales de Sun.

Explicación para la parte 1: Cambié al modo de 64 bits, usé sudo y sudo el comando como usuario de Tomcat.

Nota: la Parte 2 podría no ser necesaria. Para algunos usuarios, parece que la parte 1 es suficiente. De hecho, intente agregar solo el comando sudo primero. Puede que ya lo haga el truco.

Para aquellos que encuentran esta respuesta seis años después de que se les preguntó y están en CentOS 7, tengan en cuenta que SELinux evitará que jmap escriba los volcados de almacenamiento dinámico ya que, de entrada, negará la escritura a un socket a menos que el directorio tenga el tipo tomcat_tmp_t .

En mi caso, escribo mis volcados de heap bajo /usr/share/tomcat/.jmap . Este directorio es propiedad de mi usuario en tiempo de ejecución.

Por lo tanto, para permitir que jmap escriba en este directorio:

semanage fcontext -a -t tomcat_tmp_t "/usr/share/tomcat/.jmap(/.*)?" restorecon /usr/share/tomcat -vR

Lo cual nos permite ejecutarlo, como nuestro usuario de tomcat:

jmap -dump:format=b,file=/usr/share/tomcat/.jmap/tomcat-`date +%s`.bin <pid>

Para los usuarios de Tomcat que tengan este problema, verifique su archivo de registro catalina.out.

Estaba teniendo los mismos problemas "22693: No se puede abrir el archivo de socket: el proceso de destino no responde o la VM de HotSpot no está cargada". Me di por vencido y estaba tratando de encontrar algo sobre lo que sucedía antes de que cerrara, pero luego estaba la salida jstack en el archivo de registro.

Tuve el mismo problema, pero ninguna de las siguientes soluciones funcionó para mí:

jstack <pid> jstack -J-d64 -m <pid> sudo -u <user> jstack ...

Finalmente actualicé JDK de jdk1.6.0_24 a jdk1.7.0_67 y todo funcionó.