jstack - file noto non è sicuro

Question

Sto eseguendo tomcat 5.5 su x86_64 CentOS 5.7 utilizzando Oracle Java 1.6.0 a 32 bit.

Processo JVM utilizzato da tomcat con 6421 pid. Tomcat sta funzionando bene.

Quando viene eseguito jstack non riesce con:

[root@mybox ~]# jstack 6421 
6421: well-known file is not secure 

per ottenere qualsiasi uscita ragionevole, ho bisogno di usare l'opzione forza:

[root@mybox ~]# jstack -F 6421 
Attaching to process ID 6421, please wait... 
Debugger attached successfully. 
Server compiler detected. 
JVM version is 17.0-b16 
Deadlock Detection: 

No deadlocks found. 
(...) 

Le domande sono:

1. che cosa fa il messaggio di errore "file noto i s non sicuro " significa?
2. qual è il file "noto"?
3. perché/quando il comando jstack non funziona senza un'opzione di forzatura?

Grazie in anticipo.

Answer 1

Ciò è probabilmente dovuto al file in/tmp usato per comunicare con il procedimento avente autorizzazioni diverse rispetto a quella del jstack ottiene. Il file in questione è/tmp/hsperfdata_ $ USER/$ PID.

Non so perché funziona con -F come la pagina man dice "Forza un dump dello stack quando 'jstack [-l] pid' non risponde."

Answer 2

Quando si utilizza -F, il JVM sarà congelato.

Se è possibile trovare il file: /tmp/hsperfdata_$USER/$PID. Basta provare a passare a $USER e quindi a exec jstack. Si sta eseguendo con "root", ma tale processo potrebbe non appartenere a root.

se $USER non ha una shell di accesso (ad es.utenti demone), e quindi non è possibile passare a quell'utente, è possibile aggirare il problema utilizzando sudo -u $USER jstack $PID

Answer 3

Vorrei solo aggiungere che potrebbe essere necessario specificare la directory/tmp in base all'opzione -J, poiché non tutte le app utilizzare la quella di default

jstack -J-Djava.io.tmpdir=PATH -l PID 

Answer 4

mi è stato sempre lo stesso errore in esecuzione:

watch -n .5 "jstack 26259" 

facendo come sudo funziona:

sudo watch -n .5 "jstack 26259" 

Answer 5

Se non si vuole preoccupare di utenti e può lavorare come root e stai bene di uccidere il processo, è possibile utilizzare questo ultimo ricorso:

kill -s SIGQUIT $PID 

Questo scriverà il dump thread per il registro console , per esempio, in caso di Tomcat, che richiederebbe grep per "Discussione completo" che è l'inizio della discarica filo in logs/catalina.out e quindi ottenere il file tdump come:

DUMP_IDX=`grep -n 'Full thread' logs/catalina.out | tail -1 | cut -d':' -f1` 
sed -n $DUMP_IDX,1000000000000000000p logs/catalina.out > jstack-kill-thread-dump-0309.tdump 

Answer 6

ho avuto questa problema quando ho provato a eseguire jstack come root.

Una volta passato a un altro utente, ha funzionato immediatamente.

Answer 7

Questo è l'uno di linea che uso per assicurarsi che sto utilizzando sempre le autorizzazioni utente corrette:

proc="my-process-name"; pid=`pgrep -f "${proc}"`; sudo -u "#`ps axo uid,pid | grep "${pid}" | tr -s " " | cut -f2 -d" "`" /usr/bin/jstack -l "${pid}" > /mnt/dumps/"${proc}"-`date +%s`.txt 

Answer 8

Probabilmente il modo più semplice è:

vedere il proprietario del processo attraverso il ps -ef | grep "nome processo"

quindi passare a quell'utente ed eseguire il comando.

jcmd PID GC.run o qualsiasi altra utilità java

Una cosa che ho notato che nessuno ha discusso qui è; devi anche avere il set di variabili JAVA_HOME. controllare questo da echo $ JAVA_HOME