SNMP Process OIDs: hrSWRunTable & hrSystemProcesses Reference

By the SNMP Monitoring team · Reviewed July 2026

Two different questions live under "process monitoring," and SNMP answers them with two different objects. "How many processes are running?" is a single scalar — hrSystemProcesses. "Is this specific process running, and what's it using?" is a table walk — hrSWRunTable for names and status, hrSWRunPerfTable for per-process CPU and memory. This page is the paste-ready reference for all three, straight from HOST-RESOURCES-MIB.

The "how do I alert if a daemon dies" side is the twin: monitor processes. Hubs: sensors, all OIDs.

hrSystemProcesses (count)

The simplest one — a single scalar with the current number of processes:

• OID: 1.3.6.1.2.1.25.1.6.0
• Type: Gauge32 (current count, not a counter)
• Use: a fast, cheap "is the process count sane" signal — a runaway fork bomb or a stuck service spawning children shows up as an abnormal count

Append the trailing .0 for a GET; it's a scalar, not a table. Good for a coarse trend, useless for "which process" — that's what the table below is for.

hrSWRunTable columns

The per-process inventory at 1.3.6.1.2.1.25.4.2.1, one row per running program, indexed by a run-index:

You'd typically walk hrSWRunName to find the row for your daemon (say nginx), note its index, then read hrSWRunStatus at that index to confirm it's alive.

hrSWRunPerfTable

Per-process resource use lives in a parallel table at 1.3.6.1.2.1.25.5.1.1, sharing the same run-index as hrSWRunTable:

• hrSWRunPerfCPU — 1.3.6.1.2.1.25.5.1.1.1 — total CPU consumed by the process, in centiseconds (hundredths of a second). It's cumulative, so diff two reads for a rate.
• hrSWRunPerfMem — 1.3.6.1.2.1.25.5.1.1.2 — memory allocated to the process, in kilobytes.

Because the index matches hrSWRunTable, hrSWRunName.<i> names the process whose hrSWRunPerfMem.<i> you're reading. That join is how you turn "row 4123 uses 512 MB" into "postgres uses 512 MB."

Status enum values

hrSWRunStatus (.7) is the field you alert on, and its values are:

• running(1) — actively executing
• runnable(2) — ready to run, waiting for CPU
• notRunnable(3) — loaded but not runnable (e.g. waiting on a resource)
• invalid(4) — not a valid entry / defunct

For a health check, running(1) or runnable(2) is normal; a process you expect that's absent from the table entirely, or sitting at invalid(4), is the problem. Note that "process not in the table at all" is the more common failure signal than a specific status value — a crashed daemon simply disappears.

That "absence, not status" point deserves emphasis, because it changes how you build a check. You can't poll a fixed OID for "is nginx running," because the row index for nginx isn't stable and vanishes entirely when the process dies — there's no hrSWRunStatus to read for a process that no longer exists. So the reliable pattern is a walk-and-match:

1. Walk hrSWRunName (.2) every poll to get the current set of process names.
2. Compare that set against the daemons you expect to be present.
3. Alert when an expected name is missing from the returned set.
4. As a secondary check, read hrSWRunStatus for a present process to catch one that's wedged at invalid(4). A second caveat on big or busy hosts: the run table can be large and it churns constantly as short-lived processes come and go, so walking it has a real cost — poll it at a sensible interval, and scope your allowlist to the handful of daemons that actually matter rather than diffing the entire process list every cycle.

Worked snmpwalk example

Walk process names, then status:

snmpwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.4.2.1.2

HOST-RESOURCES-MIB::hrSWRunName.1 = STRING: "systemd"
HOST-RESOURCES-MIB::hrSWRunName.412 = STRING: "sshd"
HOST-RESOURCES-MIB::hrSWRunName.998 = STRING: "nginx"

nginx is at index 998 — read its status and memory:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.4.2.1.7.998 1.3.6.1.2.1.25.5.1.1.2.998

HOST-RESOURCES-MIB::hrSWRunStatus.998 = INTEGER: running(1)
HOST-RESOURCES-MIB::hrSWRunPerfMem.998 = INTEGER: 20480 KBytes

And the total count in one GET:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.25.1.6.0

HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 214

<RO_string> is a placeholder — the process table can expose command-line arguments, so allowlist it deliberately and keep live communities out of scripts.

How to monitor processes (how-to)

Reference ends here. The alerting logic — checking a named daemon is present, catching a process that vanished, watching per-process CPU/memory growth — is the twin: monitor processes via SNMP. Related: CPU OIDs, memory OIDs, the OID catalog, and glossary.

Frequently asked questions

What OID lists running processes?

The hrSWRunTable at 1.3.6.1.2.1.25.4.2.1. Walk hrSWRunName (.2) for process names, hrSWRunPath (.4) for the executable path, and hrSWRunStatus (.7) for run state. Each row is one running program, indexed by a run-index.

What OID is the process count?

hrSystemProcesses at 1.3.6.1.2.1.25.1.6.0 — a Gauge32 with the current number of processes. It's a scalar (note the trailing .0), useful as a cheap sanity signal for fork storms or a stuck service, though it can't tell you which process.

What does hrSWRunStatus mean?

It's the run-state enum in hrSWRunTable at 1.3.6.1.2.1.25.4.2.1.7: running(1), runnable(2), notRunnable(3), invalid(4). For a health check, running or runnable is normal; a process that's expected but missing from the table, or shown invalid, is the failure to alert on.

How do I get per-process CPU?

Read hrSWRunPerfCPU at 1.3.6.1.2.1.25.5.1.1.1 for the row — it's cumulative CPU time in centiseconds, so sample twice and diff for a rate. Memory is hrSWRunPerfMem (.2) in kilobytes. Both share the hrSWRunTable index, so join on it to name the process.

Key takeaways

• Count: hrSystemProcesses (1.3.6.1.2.1.25.1.6.0), a Gauge32 scalar.
• Inventory: hrSWRunTable (1.3.6.1.2.1.25.4.2.1) — name .2, path .4, params .5, type .6, status .7.
• Status enum: running(1) / runnable(2) / notRunnable(3) / invalid(4) — a missing row is the common failure.
• Per-process resources: hrSWRunPerfTable (1.3.6.1.2.1.25.5.1.1) — CPU .1 (centiseconds), mem .2 (KB).
• The perf table shares the hrSWRunTable index — join to name the process.
• Procedure: processes how-to; catalog: sensors/all.