Diagnostics — processes#
The Processes tab prints the router's own process table. It exists so that "is that daemon actually running" does not require an SSH session, and because the honest answer to "why is this box busy" often starts with a list.
GET /api/processes is show system processes on the router. The output is ps-style
text, parsed into five fields — handleProcesses and parseProcesses in
agent/opmode.go. The page polls it every 10 s.
The four tiles#
| Tile | Value |
|---|---|
| Processes | Total rows parsed. |
| Kernel threads | Rows whose command is bracketed, e.g. [kworker/0:1]. The subtext says "shown in [brackets]". |
| Userspace | Total minus kernel threads. |
| Zombies | Rows whose state starts with Z. Amber when any exist. |
The kernel-thread split is the useful one on a small router: several hundred processes
of which nearly all are [bracketed] is a normal idle box, not a busy one.
A non-zero zombie count is worth chasing. A zombie is a finished process whose parent has not reaped it; a handful that clear on their own are noise, and a count that only grows means a parent process is not doing its job.
The table#
| Column | Field | Notes |
|---|---|---|
| PID | first field | Sorts numerically. |
| State | third field | A badge: green when it starts with R (running), red when it starts with Z (zombie), neutral otherwise. |
| CPU time | fourth field | Accumulated processor time, as ps prints it. |
| TTY | second field | Usually ? for anything not attached to a terminal. |
| Command | everything after the fourth field | The command line, joined back together. |
The command column is everything after the first four fields, deliberately, because a command line contains spaces and splitting on whitespace alone would truncate every process to its first word. A row with fewer than five fields is skipped as unparseable rather than half-rendered.
The Filter by command… box searches the table; the list scrolls inside a 60-viewport-height box rather than pushing the page down. Sorting works on every column.
The empty state names the command to run at the console: show system processes.
What it is good for#
| Question | How to use the tab |
|---|---|
| Is the agent running? | Filter for wheelhouse-agent. |
| Is a container up? | Filter for podman or conmon; the app page is a better answer. |
| Is the IDS engine running? | Filter for suricata. |
| Is something eating CPU time? | Sort by CPU time descending. Note that this is accumulated time, so a long-lived daemon sorts high without being busy now. |
| What is this box even doing? | The Userspace tile, then the filter. |
What this tab will not do#
- No instantaneous CPU or memory per process. The parsed fields are PID, TTY, state,
accumulated CPU time and the command. There is no
%CPU, no%MEMand no RSS column. Sorting by CPU time is not the same as finding what is busy right now. - No kill, no restart, no renice. It is entirely read-only. Nothing on this page sends a signal to anything.
- No per-process history. Every poll replaces the table.
- No tree. Processes are a flat list; there is no parent-child view.
For the memory and load picture, use the tiles on the Dashboard or System — overview. For what a specific service is doing, the journal is usually the better tool.
See also#
- Diagnostics — the other five tabs.
- Companions — configuration state for three services, which is a different question from "is the process alive".
- Logs — what a process is saying.
Checked against ui/src/pages/Diagnostics.tsx,
agent/opmode.go, agent/main.go.