During the trouble-shooting of Jenkins, we often request that you obtain thread dumps of relevant Java VMs. Thread dumps concisely captures what every thread in a VM is doing at a given point in time, and therefore it is useful to diagnose hang problems, deadlocks, and performance issues. This page explains how you obtain it.
From Jenkins Web UI
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.
By using jstack
If Jenkins is not responding to web UI, try jstack to obtain the thread dump. For one reason or another that none of us quite understand well, one 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
jstack
isn't always reliable, and sometimes it fails to obtain thread dumps for no obvious reasons.
By sending signal
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 use a tool like this to send a signal (Windows).
Obviously, you must be on the same machine as the Jenkins master 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/1
to figure out which file the stdout is being written to. On Windows, if you have installed Jenkins as a Windows service, check that page for whereabouts of the log files.
This approach is platform specific, but it tends to be more reliable even when JVM is in a dire state.