jstack - よく知られているファイルがセキュアでない

32ビットOracle Java 1.6.0を使用してx86_64 CentOS 5.7でtomcat 5.5を実行しています。jstack - よく知られているファイルがセキュアでない

tomcatで使用されるJVMプロセスには6421 pidがあります。 Tomcatは正常に動作しています。

それがで失敗jstackを実行します。任意の合理的な出力を得るには

[[email protected] ~]# jstack 6421 
6421: well-known file is not secure

、私はforceオプションを使用する必要があります。

[[email protected] ~]# 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. 
(...)

ある質問：

エラーメッセージ"よく知られているファイルi安全でない "平均？

"よく知られている"ファイルとは何ですか？

なぜ強制オプションなしでjstackコマンドが機能しないのですか？

ありがとうございます。

出典

2012-02-01 Michał Šrajer

tomcatはどのくらい実行されていますか？ CentOS/RHELは、数日後に/ tmpからファイルをうっかり削除します（私は何人か忘れてしまいます）。 –

@PaulCager： 'jstack'を実行する前に約1分再起動しました –

ヒープダンプを実行するために' jmap'を実行する場合も同様です。 –

おそらく、/ tmpにあるファイルが、jstackと異なるアクセス権を持つプロセスと通信するために使用されている可能性があります。問題のファイルは/ tmp/hsperfdata_ $ USER/$ PIDです。

-Fがmanページとして動作する理由がわからない場合は、「 'jstack [-l] pid'が応答しないときにスタックダンプを強制してください。 -Fが使用されている場合

出典

2012-02-01 17:46:39

私はhsperfdata *ファイルと同じグループにいなかったので、同じ問題がありました。 "newgrp other-group"で私のグループを変更しました。 –

私はrootとして実行しています。 jstackまたはjcmdを実行しても、同じメッセージが出力されます。/tmp/hsperfdata_root/pidというフォルダがあり、アクセス権があります。 – dmachop

@dmachop 'jstack'を実行するために使用されているuid：gidは、よく知られているファイルのuid：gidと一致しなければなりません。 rootとして実行してもチェックが無効にならず、 'sudo -u youruser -g yourgroup jstack ...'が正しいuid：gidになるようにすることができます。 – Nick

、JVMは、凍結になります。

file: /tmp/hsperfdata_$USER/$PIDが見つかる場合は、 $USERに切り替えてから、exec jstackに切り替えてみてください。 "root"で実行していますが、そのプロセスがrootに属していない可能性があります。

$USERにログインシェルがない場合（つまり、デーモンユーザー）、そのユーザーに切り替えることはできませんので、これを回避するにはsudo -u $USER jstack $PID

出典

2012-04-17 09:15:18

+10

$ USERにログインシェル（デーモンユーザ）がなく、そのユーザに切り替えることができない場合は、 'sudo -u $ USER jstack $ PID'を使ってこの問題を回避できます。 –

すべてのアプリケーションではないため、-Jオプションで/ tmpディレクトリを指定する必要があることを追加したいと思います私は同じエラーランニングを得ていた1

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

出典

2013-05-14 01:27:10 iddqd

デフォルトを使用します。

sudoのようこう

watch -n .5 "jstack 26259"

それが動作：

sudo watch -n .5 "jstack 26259"

を

出典

2015-05-15 20:55:10

ユーザーを心配する必要はありませんし、ルートとして動作することができますし、プロセスを強制終了しても大丈夫な場合は、この最後の手段を使用することができます。

kill -s SIGQUIT $PID

このコンソールログにスレッドダンプを書き込みます。例えば、Tomcatの場合には、ログ/ catalina.outでスレッドダンプの始まりである「全スレッド」のためにgrepをし、その後としてtdumpファイルを取得している必要がある：

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

出典

2016-03-10 01:07:00 kisna

私はこれを持っていました私がjstackをrootとして実行しようとしたときの問題。

もう一度別のユーザーに切り替えるとすぐに機能しました。

出典

2016-06-16 11:52:54

これは私のために働いた。私のアプリケーション（jvmtop）をJavaプロセスが実行されている同じユーザーとして実行し、エラーメッセージとエラーが消えた... – rogerdpack

これは私が常に正しいユーザー権限を使用していることを確認するために使用する1つのライナーです：

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

出典

2017-09-19 12:17:10 douglaslps

おそらく最も簡単な方法は次のとおりです。

PSでプロセスの所有者を参照してください-ef | grep "プロセス名"

次に、そのユーザーに切り替えてコマンドを実行します。誰もがここで説明されていないことを

jcmd PID GC.runまたはその他のJavaユーティリティ

ことの一つは、私は気づきました。 JAVA_HOME変数を設定する必要もあります。これを確認してください echo $ JAVA_HOME

出典

2017-10-13 14:49:27

jstack - よく知られているファイルがセキュアでない

答えて

関連する問題