Count the running processes
Report how many processes are alive — useful for load testing, capacity baselining, or detecting fork-bomb / runaway-parallelism conditions.
How to count the running processes in each shell
pgrep -c .`pgrep -c PATTERN` counts matches. `.` matches every process. POSIX-portable. Alternative: `ps -e | tail -n +2 | wc -l` (subtract header — POSIX). Avoid GNU-only `ps -e --no-headers | wc -l` (not on macOS/BSD).
pgrep -c .pgrep -c .@(Get-Process).Count`@()` array subexpression operator forces array — without it, single-result returns `$null`/`object`, breaking `.Count`. With `@()`, empty → 0, single → 1, many → N. Always wrap with `@()` when counting.
tasklist /fo csv /nh | find /c /v ""`/fo csv` = CSV format, `/nh` = no header. `find /c /v ""` counts ALL lines (lines not containing "" = every line). Returns "ALLO: N" — parse out the number, or pipe through `for /f`.
Equivalents listed for Bash, Zsh, Fish, PowerShell, cmd.exe.
Gotchas & notes
- **`ps -e | wc -l` over-counts by ONE** (the header line). Variants to know: GNU `ps -e --no-headers | wc -l` (omits header — but flag not in BSD/macOS); `ps -e | tail -n +2 | wc -l` (POSIX — skip first line); `pgrep -c .` (cleanest — count all PIDs matching `.` regex). Process count varies BY SECOND on most systems (short-lived shell scripts spawn + die) — for monitoring, sample over a few seconds and take median, not single snapshot.
- **Threads vs processes**: `ps -e` shows PROCESSES (one entry per PID). `ps -eLf` (`-L` = light/threads) shows THREADS (one entry per LWP). On Linux, every kernel-managed thread has a `tid` in `/proc/PID/task/TID`. A multi-threaded JVM with 200 worker threads appears as 1 process but 200 threads. Anti-pattern: counting threads when you meant processes — "we have 50,000 threads alive" is normal for a busy Java fleet; "we have 50,000 processes" indicates fork-bomb. Use `ps -e` for processes, `ps -eL` for threads. pwsh `(Get-Process).Count` is process count; per-process thread counts via `Get-Process -Name java | Select Threads | Measure -Sum -Property Count`.
- **Per-user / per-process-state counts**: `ps -e -o user= | sort | uniq -c | sort -rn` — count processes per user, highest first. `ps -e -o stat= | sort | uniq -c` — count by state code (R=running, S=sleeping, D=uninterruptible sleep, Z=zombie). High Z count = parent forgot to `wait()` for children (common bug in C servers and shell scripts that background jobs without disowning). High D count = I/O hangs (storage problem). Both indicate something deserves investigation; just counting total processes hides these.
- **Linux pid_max ceiling**: `cat /proc/sys/kernel/pid_max` shows the maximum PID value (default 32768 on 32-bit systems, 4194304 on 64-bit). When PID counter rolls over, fork() returns the lowest available PID — process IDs are recycled, not monotonic. For HIGH-FORK-RATE systems, raise `pid_max` to avoid collisions in monitoring tools that key by PID without timestamp. macOS: no exposed equivalent, system-managed. Windows: ProcessId is 32-bit, recycling can produce false matches across reboots — most monitoring tools track ProcessId+StartTime as the unique key.
- **Cgroup-scoped counts in containers**: `ps -e` inside a Docker container with default PID namespace shows ONLY processes in that container — `wc -l` returns the container's count, not the host's. `ps -ef --pid=$(cat /sys/fs/cgroup/cgroup.procs)` lists processes in the current cgroup (cgroup v2). For host-wide count from inside a privileged container: bind-mount `/proc/host` and `ps -e --pid-host` (requires `/proc:rw` mount — security-sensitive). K8s `kubectl describe node` shows total pods + capacity; for runtime process count per pod, exec in and `ps -e | wc -l`.
Related commands
Related tasks
- Find processes using the most CPU— List the top CPU-consuming processes — useful for performance triage, runaway-script detection, and capacity planning.
- Show the process tree— Render the parent/child relationships between running processes — useful for tracing rogue children, debugging fork bombs, and understanding shell-spawned subprocess chains.
- Monitor CPU and memory live— Watch CPU and memory utilisation continuously from a shell — for triage, capacity planning, and detecting transient spikes that a one-shot ps would miss.
- Find a process ID by name— Look up the PID(s) of a running process given its executable name — the lookup that precedes most kill / signal / inspect operations.