web-dev-qa-db-fra.com

jstack: le processus cible ne répond pas

J'utilise Ubuntu Server Edition et je voulais faire un vidage de threads de Tomcat.

J'ai donc d'abord essayé de savoir quel PID Tomcat utilise:

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

Mais ce n'est pas là?

J'ai donc utilisé top à la place et découvert le PID 5730.

Ensuite, j'ai appelé jstack pour obtenir le vidage de thread:

$ 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 se passe-t-il? :

J'ai déjà essayé d'exporter CATALINA_TMPDIR comme décrit dans --- (Jstack et Jstat ont cessé de fonctionner avec la mise à niveau vers JDK6u2 mais cela n'a rien changé:

$ 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

Mise à jour:

J'ai aussi essayé Sudo -u Tomcat6 jstack -l -F 5730 > threaddumpexceptions2.txt mais cela ne me donne que des tonnes d'exceptions sur la console.

javajstackthread-dump
44
Timo

Je l'ai fait fonctionner en faisant deux choses:

  1. Appel remplacé par: Sudo -u Tomcat6 jstack -J-d64 -m pid
  2. OpenJDK a été remplacé par les packages originaux Sun-6-jdk et Sun-6-jre de Sun

Explication pour la partie 1: Je suis passé en mode 64 bits, j'ai utilisé Sudo et j'ai exécuté la commande en tant qu'utilisateur Tomcat.

Remarque: La partie 2 peut ne pas être nécessaire. Pour certains utilisateurs, il semble que la partie 1 soit suffisante. En fait, essayez tout d'abord d'ajouter simplement la commande Sudo. Cela pourrait déjà faire l'affaire.

68
Timo

Je pense que vous devez exécuter jstack en tant que même utilisateur qui exécute le processus Tomcat. Notez également que jps ne renvoie que des processus pour l'utilisateur actuel. Vous obtiendrez le pid pour le processus Tomcat en exécutant jps avec Sudo ou en tant qu'utilisateur du processus Tomcat.

Ce rapport de bogue peut également être utile: https://bugs.launchpad.net/ubuntu/+source/Sun-Java6/+bug/597098

30
Michael Pigg

@Valmar, je trouve le même sujet ici. Impossible d'obtenir le vidage des threads? Des idées pourquoi mon application se bloque?

Il semble que la solution de contournement soit Sudo -u Tomcat6 kill -3 <pid>.

3
Clark Bao

Je trouve utile d'utiliser quelque chose comme 'ps -eo pid, user, command | grep Java 'pour trouver la véritable commande Java utilisée, puis utilisez le répertoire pour trouver le jstack correspondant, 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)

Donc, son 64 bits, fonctionnant en tant que "someuser". su à cet utilisateur et exécutez run jstack etc. à partir de ce même répertoire. (par exemple./usr/lib/jvm/Java/bin/jstack

Utile lorsque vous êtes sur un serveur avec différentes installations/implémentations différentes de Java.

1
Cameron Kerr

Cela a également fonctionné pour moi:

Sudo -u Tomcat6 kill -3 pid

Il semble que rien ne se passe, mais lorsque vous regardez dans les journaux, les piles sont là. Ils ressemblent à des exceptions si vous ne vous y attendez pas.

1
Ted Bigham

Essayez de passer à l'utilisateur de processus, puis utilisez jstack:

Sudo -u {utilisateur de processus} jstack> dump

1
Joshua

Pour les utilisateurs Tomcat rencontrant ce problème, vérifiez votre fichier journal catalina.out.

J'avais les mêmes problèmes "22693: Impossible d'ouvrir le fichier socket: le processus cible ne répond pas ou HotSpot VM non chargé". J'ai abandonné et j'essayais de trouver quoi que ce soit sur ce qui s'est passé avant qu'il ne se verrouille , mais il y avait ensuite la sortie jstack dans le fichier journal.

0
John C

Pour ceux qui trouvent cette réponse six ans après qu'elle a été posée et ils sont sur CentOS 7 notez que SELinux arrêtera jmap d'écrire les vidages de tas car, hors de la boîte, il refusera d'écrire sur un socket sauf si le répertoire a le type Tomcat_tmp_t.

Dans mon cas, j'écris mes vidages de tas sous /usr/share/Tomcat/.jmap. Ce répertoire appartient à mon utilisateur d'exécution.

Par conséquent, pour permettre à jmap d'écrire dans ce répertoire:

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

Ce qui nous permet ensuite de lancer, en tant qu'utilisateur Tomcat:

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

J'ai eu le même problème, mais aucun de la solution ci-dessous a fonctionné pour moi:

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

J'ai finalement mis à jour JDK de jdk1.6.0_24 à jdk1.7.0_67 et tout a fonctionné.

0
MK Aftab