Obtaining a thread dump

This site is the new docs site currently being tested. For the actual docs in use please go to https://www.jenkins.io/doc.

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.

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. 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.

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).

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/1 to figure out which file the stdout is being written to. If you are running as a Windows service, see the Windows installation instructions for the log file location.

This approach is platform specific, but it tends to be more reliable even when JVM is in a dire state.