During the troubleshooting of Jenkins, others may request that you obtain thread dumps of relevant Java VMs. Thread dumps concisely capture what every thread in a VM is doing at a given point in time. They are useful to diagnose hang problems, deadlocks, and performance issues. This page explains how you can obtain a thread dump.
This is the simplest way of obtaining thread dumps.
If Jenkins or its build agents are operating normally, you can obtain a thread dump remotely by going to
http://your.jenkins.server/threadDump. For an agent named 'xyz', go to
http://your.jenkins.server/computer/xyz/systemInfo. You need to have the administrator permission on the system.
If Jenkins is not responding to web UI, tryjstack获得the thread dump. You might have to add -F to get the dump. If that was the case, please mention that in the report as well.
Make sure to run jstack as the same user that’s running Jenkins itself instead of using the root user.
If the above two approaches do not work, you can still have the JVM print the thread dump to its stdout by sending it a signal.
If you have a terminal or command prompt that’s running the JVM, you can hit Ctrl+ + (Unix) or Ctrl+Break (Windows) to do this. If the JVM is running in background, you do this by
kill -3 PID(Unix) or usea tool like thisto send a signal (Windows).
You need to be on the same machine as the Jenkins controller when you run this command. In a situation like this, the standard output of JVM is normally redirected to a log file, so you need to hunt down where it is written to and pick up the dump from there. On Unix, you can look at
/proc/PID/fd/1to figure out which file the stdout is being written to. If you are running as a Windows service, see theWindows installation instructionsfor the log file location.
This approach is platform specific, but it tends to be more reliable even when JVM is in a dire state.