Jstack не работает на сервере - PullRequest
15 голосов
/ 16 ноября 2011

Мы используем jstack на серверах, чтобы определить, не заблокированы ли java-приложения. Он не работает на одном из наших серверов Linux. Я думаю, что версия O / S:

$cat /etc/issue.net
Red Hat Enterprise Linux Server release 5.6 (Tikanga)
Kernel \r on an \m

Версия Java, работающая на сервере:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode)

Когда я пытаюсь:

jstack 19114

Я получаю:

19114: 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

Когда я пытаюсь:

jstack -F 19114

Я получаю:

Attaching to process ID 19114, please wait...
Debugger attached successfully.

Deadlock Detection:

No deadlocks found.

Thread 19180: (state = BLOCKED)
Error occurred during stack walking:
sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet(LinuxDebuggerLocal.java:466)
        at sun.jvm.hotspot.debugger.linux.LinuxThread.getContext(LinuxThread.java:65)
        at sun.jvm.hotspot.runtime.linux_amd64.LinuxAMD64JavaThreadPDAccess.getCurrentFrameGuess(LinuxAMD64JavaThreadPDAccess.java:92)
        at sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaThread.java:256)
        at sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaThread.java:218)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:76)
        at sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
        at sun.jvm.hotspot.tools.JStack.run(JStack.java:60)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
        at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jstack.JStack.runJStackTool(JStack.java:118)
        at sun.tools.jstack.JStack.main(JStack.java:84)
Caused by: sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs failed for a lwp
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.getThreadIntegerRegisterSet0(Native Method)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$800(LinuxDebuggerLocal.java:51)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1GetThreadIntegerRegisterSetTask.doit(LinuxDebuggerLocal.java:460)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:127)

Кто-нибудь знает, что вызывает это?

Ответы [ 4 ]

15 голосов
/ 21 февраля 2012

Требуется запустить jstack от имени того же пользователя, который запустил процесс Java. Это устраняет вышеприведенную ошибку трассировки стека. Смотрите это сообщение: Ошибка дампа потока jstack: get_thread_regs не удалось для lwp для более подробной информации. Как только я выполнил команду jstack, ошибка исчезла.

4 голосов
/ 20 мая 2017

Синтаксис просто:

sudo -u USERID jstack PID

Пример:

sudo -u tomcat7 jstack 2498
2 голосов
/ 04 сентября 2012

Может использовать jsp, который выдает аналогичный вывод.

После jsp информация о стеке потоков выводится на экран, но вы также можете изменить вывод в файл или использовать его в обычном классе POJO.

<%@ page import="java.util.*" %><%
    Map<Thread,StackTraceElement[]> map = Thread.getAllStackTraces();
    Set tt = map.keySet();
    Iterator<Thread> ti = tt.iterator();
    Thread thrd = null;
    final String br = "<" + "br" + ">";//website does not parse it
    try{

        int cnt = 1;
        StackTraceElement[] st = null;
        while(ti.hasNext() ){
            thrd = ti.next();
            out.print(br + "<" + "hr" + ">" + br + cnt + " \"" + thrd.getName());
            out.println("\", priority :" + thrd.getPriority()  + ", state :" + thrd.getState());

            out.print(", id :" + thrd.getId() + ", hex :" +  Long.toHexString(thrd.getId()) );
            out.print(" alive :"  + thrd.isAlive() + ", daemon :" + thrd.isDaemon() );
            out.print(" interrupted  :"  + thrd.isInterrupted() + ", daemon :" + thrd.isDaemon() );
            out.print(".\n" + br);
            st = thrd.getStackTrace();
            for(int sti = 0; sti < st.length; sti++){
                out.println(br + " &nbsp; &nbsp; " + st[sti].getClassName() + "." + st[sti].getMethodName());
                out.println("(" + st[sti].getFileName());
                if(st[sti].getLineNumber() < 1){
                    out.print("Native method");
                }else{
                    out.print(":" + st[sti].getLineNumber());
                }
                out.println(")");
            }

            out.println("");
            cnt++;
        }
    }catch(Exception e){
        out.println(br + "err " + e + br);
    }




%>

Пример вывода:

121 "Thread-40", приоритет: 6, состояние: WAITING, id: 134, hex: 86 в живых: true, демон: false прерван: false, демон: false.

java.lang.Object.wait (собственный метод Object.java)
java.lang.Object.wait (Object.java: 485)
org.jpos.iso.ISOMUX $ Receiver.run (ISOMUX.java: 326)
java.lang.Thread.run (Thread.java: 662)

122 "Thread-48", приоритет: 5, состояние: TIMED_WAITING, id: 142, hex: 8e жив: true, демон: false прерван: false, демон: false.

java.lang.Thread.sleep (собственный метод Thread.java)
org.jpos.apps.qsp.QSP.monitorConfigFile (QSP.java: 301)
org.jpos.apps.qsp.QSP.run (QSP.java: 346)
java.lang.Thread.run (Thread.java: 662)

2 голосов
/ 16 ноября 2011

Попробуйте использовать kill -3 <pid> вместо этого, чтобы получить трассировку стека вашей виртуальной машины.

...