Подтвердить что ты не робот

Jstack - известный файл не защищен

Я запускаю tomcat 5.5 на x86_64 CentOS 5.7, используя 32-разрядный Oracle Java 1.6.0.

Процесс JVM, используемый tomcat, имеет 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.
(...)

вопросы:

  • Что означает сообщение об ошибке "Известный файл не является безопасным"?
  • что такое "известный" файл?
  • почему/когда команда jstack не работает без параметра force?

Спасибо заранее.

4b9b3361

Ответ 1

Вероятно, это связано с тем, что файл в /tmp используется для связи с процессом, имеющим разные разрешения, чем тот, который получает jstack. Этот файл является /tmp/hsperfdata _ $USER/$PID.

Не знаю, почему это работает с -F, поскольку справочная страница просто говорит: "Принудительный сброс стека, когда jstack [-l] pid" не отвечает ".

Ответ 2

когда используется -F, jvm будет заморожен.

Если вы можете найти file: /tmp/hsperfdata_$USER/$PID. Просто попробуйте переключиться на $USER, а затем exec jstack. Вы работаете с root ", но этот процесс может не принадлежать root.

если $USER не имеет оболочки входа (т.е. пользователей-демонов) и, следовательно, не может переключиться на этого пользователя, вы можете обойти это, используя sudo -u $USER jstack $PID

Ответ 3

У меня возникла эта проблема, когда я попытался запустить jstack как root.

Как только я переключился на другого пользователя, он немедленно сработал.

Ответ 4

Я просто хотел бы добавить, что вам может потребоваться указать ваш каталог /tmp по опции -J, так как не все приложения используют стандартный

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

Ответ 5

Я получал ту же ошибку:

watch -n .5 "jstack 26259"

Выполнение как sudo:

sudo watch -n .5 "jstack 26259"

Ответ 6

Если вы не хотите беспокоиться о пользователе и можете работать как root, и все в порядке, чтобы убить процесс, вы можете использовать это последнее средство:

kill -s SIGQUIT $PID

Это будет записывать дамп потока в ваш консольный журнал, например, в случае Tomcat, для чего потребуется grepping для "Full Thread", который является началом дампа потока в logs/catalina.out, а затем получения 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

Ответ 7

Это один лайнер, который я использую, чтобы убедиться, что я всегда использую правильные разрешения пользователя:

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

Ответ 8

Вероятно, самый простой способ:

см. владельца процесса  ps -ef | grep "имя процесса"

затем переключитесь на этого пользователя и запустите команду.

jcmd PID GC.run или любая другая утилита java

Одна вещь, которую я заметил, что никто не обсуждает здесь; вам также необходимо установить переменную JAVA_HOME. проверьте это echo $JAVA_HOME