Read Linux Process Trees Clearly with pstree
You will finish with a practical way to trace a Linux process back to its parent, identify the exact PIDs involved, and tell the difference between a compact display and missing information. The examples use pstree from psmisc 23.7, installed on this machine.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about ten minutes. You need a shell and a running Linux system with pstree installed. The commands are read-only and normally need no elevated privileges. A root shell can see more processes when the host restricts access to /proc, but do not use sudo merely to make a confusing tree look fuller.
1. Check the installed command
Confirm which executable is being run and record its version. This avoids explaining options from a different implementation:
$ command -v pstree
/usr/bin/pstree
$ pstree --version
pstree (PSmisc) 23.7
Your version line may include different copyright text. The important check is that the command is PSmisc pstree. The companion name pstree.x11 uses the same tree functionality but waits for Return at the end, which is useful in an X terminal and easy to mistake for a hung command.
Checkpoint: if command -v pstree prints nothing, stop here and install the psmisc package through your normal distribution process. Nothing in this guide requires a package change.
2. Start with the default tree
Run pstree without options:
$ pstree
systemd-+-NetworkManager
|-sshd---sshd---bash
`-cron
The names and branches will be different on every host. The tree is rooted at init, which is commonly the systemd process with PID 1. If several identical branches exist, pstree normally folds them into a count such as 4*[getty]. That is compaction, not proof that only one getty exists.
Tree punctuation depends on the terminal character set. If the drawing characters are awkward in a log or a narrow terminal, use ASCII explicitly:
$ pstree --ascii
Checkpoint: you should see a process name at the root and indented children beneath it. A short tree is a valid result; it may simply reflect the processes visible to your account.
3. Add PIDs before investigating a process
Use -p when a name is not precise enough. It adds each process ID in parentheses and disables compaction for processes:
$ pstree -p
systemd(1)-+-NetworkManager(996)
`-sshd(742)-+-sshd(1088)---bash(1092)
Use the PID you care about as an argument when you want only its descendants:
$ pstree -p 1088
sshd(1088)---bash(1092)
The numeric values and branches are host-specific. A process can exit between the moment you find its PID and the moment pstree reads /proc, so an empty or changed result is normal during a busy restart.
To see the ancestors as well as the selected process, add -s:
$ pstree -p -s 1092
systemd(1)---sshd(742)---sshd(1088)---bash(1092)
Checkpoint: use ps -p PID -o pid,ppid,comm,args if you need a tabular cross-check. Replace PID with digits from your own output, not the example above.
4. Inspect the command line safely
Process names alone hide the arguments that often explain a service or script. Add -a:
$ pstree -a -p 1
systemd,1
|-sshd,742 -D
`-cron,811 -f
With -a, pstree shows command-line arguments where it can read them and implicitly disables process compaction. Long arguments may still be hard to read in a terminal. Use -l to request long lines instead of truncating them to the display width or COLUMNS:
$ pstree -a -l -p 1
Treat arguments as potentially sensitive. They can contain tokens, file paths or user data, and copying a full tree into a ticket or chat may disclose them. Prefer pstree -p when names and PIDs are enough.
5. Decide how to handle threads
Threads appear beneath their process and use braces around the thread name, for example {worker}. To include full thread names when available, use -t:
$ pstree -p -t 1234
When thread detail is distracting, use -T to hide threads and show only processes:
$ pstree -p -T 1234
Do not infer that a process has stopped because its compacted thread display is brief. Compare both forms when thread activity is part of the incident.
6. Sort and scope the view
By default, processes with the same parent are sorted by name. Use -n to sort them by PID, which makes creation order easier to compare:
$ pstree -p -n 1
To inspect trees rooted at processes owned by one account, pass the user name:
$ pstree -p --arguments LOGIN_NAME
Replace LOGIN_NAME with an actual account name. A username view is not the same as a complete system view: the command may be unable to read other users' process information, especially with restrictive procfs settings such as hidepid. In that case, question marks or an incomplete tree are signals about visibility, not necessarily about process ownership.
Namespace views have similar limits. -N accepts ipc, mnt, net, pid, time, user or uts and shows individual trees for that namespace type. -S marks namespace transitions. These options are useful on container hosts, but a regular user may see only a limited view.
7. Use output modes that survive logs
For a plain-text incident record, choose ASCII and keep PIDs visible:
$ pstree --ascii --show-pids --hide-threads > process-tree.txt
$ sed -n '1,20p' process-tree.txt
The redirection creates or replaces process-tree.txt. This is the one state-changing example in the guide: it changes a local file, not the processes. If the file already matters, choose a new name or back it up first. Remove an unwanted capture only after checking its contents, because deletion is irreversible.
Colour is optional and only accepts age in this version. It marks processes newer than 60 seconds green, newer than an hour yellow, and older processes red when the terminal supports it:
$ pstree --color age
Do not use colour as evidence in a pasted log. Use PIDs, timestamps from another command, and repeat the view when timing matters.
Done means
- You confirmed the installed PSmisc version and the executable path.
- You can read the default compact tree without treating folding as missing processes.
- You use
-p,-sand a PID to trace a specific process. - You know when
-a,-l,-tand-Tclarify the view. - You recognise procfs permissions, namespaces and exiting processes as visibility limits.
- Any captured output was written to a deliberate file and did not alter a service or process.