Linux Process Management — Unkillable D State from NFS Hang

Every command you run, every web server you start, every cron job that fires at midnight — all of it becomes a Linux process. Understanding how those processes live, communicate and die isn't optional knowledge for a DevOps engineer or backend developer; it's the difference between confidently diagnosing a runaway process at 2 AM and blindly rebooting a production server and hoping for the best.

The problem most developers hit is that they learn 'ps aux | grep something' and 'kill -9' and think that's process management. It isn't. That's like learning to use a fire extinguisher but not knowing what causes fires. Real process management means understanding process states, parent-child relationships, signals, job control, and how the kernel schedules work — so you can make deliberate decisions instead of panicked ones.

By the end of this article you'll be able to inspect any running process and understand what it's doing, send the right signal for the right situation (spoiler: kill -9 is almost never the right answer), manage foreground and background jobs like a pro, and build the mental model that makes every 'why is my server slow?' investigation start from a place of clarity.

What Linux Process Management Actually Means

Linux process management is the kernel's system for creating, scheduling, and terminating processes — the fundamental units of execution. At its core, it tracks every process via a task_struct in a doubly linked list, assigns a unique PID, and manages state transitions between running, sleeping, stopped, and zombie. The scheduler (CFS) uses a red-black tree to pick the next task in O(log n) time based on vruntime, ensuring fairness across CPU cores.

Key properties: processes inherit environment via fork() with copy-on-write pages, and every process except PID 1 has a parent. The kernel maintains a runqueue per CPU, and context switches happen roughly every 1-10 ms (configurable via CONFIG_HZ). Signals, ptrace, and cgroups add control layers — but the core mechanic remains the same: the kernel decides who runs next, and user space can only influence via nice values, sched_setscheduler, or CPU affinity.

You use process management every time you run a command, start a daemon, or spawn a thread pool. Understanding it matters when debugging hangs (D state), runaway CPU (zombie children), or OOM kills — the kernel's process lifecycle directly determines system stability. Without this mental model, you're guessing at why a process won't die or why load average spikes.

How Linux Processes Are Born — PIDs, PPIDs and the Process Tree

Every process in Linux gets a Process ID (PID) — a unique integer the kernel assigns at birth. But processes don't appear from nowhere. Almost every process is spawned by another process, its parent, which holds a Parent Process ID (PPID). This parent-child relationship forms a tree, and the root of that entire tree is PID 1 — the init system (systemd on modern distros).

Why does this matter? Because when a parent process dies before its child, the child becomes an 'orphan' and gets re-parented to PID 1. When a child dies but the parent hasn't called wait() to collect its exit status, the child becomes a 'zombie' — it occupies a PID slot and a row in the process table while holding no real resources. A handful of zombies is harmless. Thousands mean something in your code is seriously wrong.

The fork-exec model is how new processes are created. A parent calls fork(), which clones itself into a child process. The child then calls exec() to replace its memory with a new program. This is why your shell is the parent of almost every command you run — and why killing your terminal kills the processes running inside it.

Run pstree to see the entire family tree live. It's one of the most clarifying commands a Linux learner can run.

#!/usr/bin/env bash
# process_tree_inspection.sh
# Goal: Understand where a process comes from and who owns it

# --- Step 1: Find the PID of the current shell ---
current_shell_pid=$$   # $$ is a special variable holding the current process's PID
echo "Current shell PID: $current_shell_pid"

# --- Step 2: Start a background sleep to give us something to inspect ---
sleep 300 &            # The & sends the process to the background immediately
sleep_pid=$!           # $! captures the PID of the last background command
echo "Background sleep PID: $sleep_pid"

# --- Step 3: Inspect the process in detail using ps ---
# -o lets us choose exactly which columns to display
# pid=process id, ppid=parent process id, stat=state, cmd=full command
echo ""
echo "--- Detailed view of our sleep process ---"
ps -o pid,ppid,stat,user,cmd -p "$sleep_pid"

# --- Step 4: Show how this process fits in the full tree ---
echo ""
echo "--- Process tree rooted at our shell ---"
pstree -p "$current_shell_pid"   # -p shows PIDs next to each process name

# --- Step 5: Clean up — kill our background sleep gracefully ---
kill "$sleep_pid"      # Sends SIGTERM (signal 15) by default — polite shutdown request
echo ""
echo "Sent SIGTERM to sleep process $sleep_pid. It should be gone now."

# --- Step 6: Confirm it's gone ---
sleep 0.2              # Give the kernel a moment to clean up
if ! kill -0 "$sleep_pid" 2>/dev/null; then
  # kill -0 doesn't actually kill — it just checks if the process exists
  echo "Confirmed: PID $sleep_pid no longer exists."
fi

Reading Process State — What ps and top Are Actually Telling You

Developers glance at ps output and look for a name. Senior engineers look at the STAT column first. That single letter (or two) tells you exactly what the kernel is doing with that process right now, and it's the fastest way to diagnose a sick system.

The core states are: R (Running or runnable — actively using CPU or waiting for a CPU slot), S (Interruptible Sleep — waiting for I/O or an event, will wake up when signalled), D (Uninterruptible Sleep — waiting on I/O it cannot be interrupted from, typically disk or NFS), Z (Zombie — dead but parent hasn't collected exit status), and T (Stopped — paused by a signal like SIGSTOP or by a debugger).

The D state is the one that causes real pain. A process in D state cannot be killed — not even with kill -9. It's waiting on the kernel for something and is completely outside the kill path until that kernel operation finishes or times out. If you see dozens of processes in D state, your storage layer is almost certainly the problem: a hung NFS mount, a failing disk, or an overloaded I/O scheduler.

top and htop give you the same state information but in real time, so you can watch a process oscillate between R and S as it processes requests — that's healthy. A process pinned in R consuming 100% CPU for minutes is not.

#!/usr/bin/env bash
# process_state_diagnosis.sh
# Goal: Show how to read process states and identify problematic ones

# --- Snapshot of all processes with state info ---
# a = all users, u = user-oriented format, x = include processes without a terminal
echo "=== Full process snapshot (top 20 by CPU) ==="
ps aux --sort=-%cpu | head -20
# Output columns: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

echo ""
echo "=== Processes currently in Uninterruptible Sleep (D state) ==="
# These are the dangerous ones — they can't be killed and indicate I/O problems
ps aux | awk '$8 ~ /^D/ { print $0 }'
# awk checks column 8 (STAT) for a value starting with D

echo ""
echo "=== Zombie processes on this system ==="
# Zombies start with Z in the STAT column
zombie_count=$(ps aux | awk '$8 ~ /^Z/ { count++ } END { print count+0 }')
echo "Zombie count: $zombie_count"
if [ "$zombie_count" -gt 0 ]; then
  echo "Zombies found — listing with parent PIDs:"
  ps aux | awk '$8 ~ /^Z/ { print $0 }'
  echo ""
  echo "To fix zombies: identify the parent (PPID) and restart it."
  echo "The parent is responsible for calling wait() to reap its children."
fi

echo ""
echo "=== Top 5 memory consumers ==="
ps aux --sort=-%mem | awk 'NR==1 || NR<=6 { print $0 }'
# NR==1 preserves the header row, NR<=6 gives us 5 data rows

Signals — The Right Way to Talk to a Running Process

A signal is a small integer the kernel delivers to a process as a notification or instruction. Most developers only know two: kill -9 and 'the other one'. That ignorance causes real production problems — from data corruption when processes don't get to flush their write buffers, to configuration changes never taking effect because an engineer restarted instead of reloaded.

The key signals every DevOps engineer must know: SIGTERM (15) is a polite shutdown request — the process can catch this, finish what it's doing, close files, and exit cleanly. This is the default signal for kill and the one you should try first. SIGKILL (9) is unconditional termination by the kernel — the process gets no say, no cleanup. Use it only when SIGTERM has failed after a reasonable wait. SIGHUP (1) means 'hang up' and historically disconnected modems, but modern daemons like nginx and sshd re-read their config files when they receive SIGHUP — no restart, no downtime. SIGSTOP (19) and SIGCONT (18) pause and resume a process, identical to what Ctrl+Z and fg do from your terminal. SIGUSR1 and SIGUSR2 are user-defined signals that applications can use for custom behaviour — some log rotation tools use these.

The kill command is misnamed — it sends signals, it doesn't exclusively kill. kill -l shows every signal your system supports.

#!/usr/bin/env bash
# signal_management_demo.sh
# Goal: Demonstrate the right signal for each situation

# --- Part 1: Graceful shutdown vs forced kill ---
# Start a simulated long-running service
sleep 600 &
long_running_pid=$!
echo "Started fake service with PID: $long_running_pid"

# The RIGHT first step — ask politely
echo "Sending SIGTERM (graceful shutdown request)..."
kill -SIGTERM "$long_running_pid"   # Same as: kill -15 $long_running_pid

# Wait up to 5 seconds for graceful shutdown
for wait_seconds in 1 2 3 4 5; do
  sleep 1
  if ! kill -0 "$long_running_pid" 2>/dev/null; then
    echo "Process exited cleanly after ${wait_seconds}s. Good."
    break
  fi
  if [ "$wait_seconds" -eq 5 ]; then
    echo "Process didn't respond to SIGTERM after 5s. Now using SIGKILL."
    kill -SIGKILL "$long_running_pid"   # Only escalate when SIGTERM fails
  fi
done

echo ""

# --- Part 2: SIGHUP for zero-downtime config reload ---
# In production you'd do: kill -SIGHUP $(cat /var/run/nginx.pid)
# Let's simulate it with a script that catches SIGHUP
cat > /tmp/signal_catcher.sh << 'SCRIPT'
#!/usr/bin/env bash
trap 'echo "[PID $$] Caught SIGHUP — reloading config (no restart needed)"' SIGHUP
trap 'echo "[PID $$] Caught SIGTERM — shutting down cleanly"; exit 0' SIGTERM
echo "[PID $$] Service started. Waiting for signals..."
while true; do sleep 1; done
SCRIPT
chmod +x /tmp/signal_catcher.sh

/tmp/signal_catcher.sh &
catcher_pid=$!
sleep 0.5   # Give it a moment to start

echo "--- Simulating config reload with SIGHUP ---"
kill -SIGHUP "$catcher_pid"         # nginx does this — reload config, keep serving traffic
sleep 0.3

echo ""
echo "--- Simulating graceful shutdown with SIGTERM ---"
kill -SIGTERM "$catcher_pid"        # Clean exit
wait "$catcher_pid" 2>/dev/null     # Wait for it to finish before exiting this script

echo ""
echo "--- All signals on this system (for reference) ---"
kill -l   # Print all signal names and numbers

Job Control — Managing Foreground, Background and Suspended Processes

Job control is the shell's built-in mechanism for managing multiple processes from a single terminal session. It's the feature that lets you start a long compile, push it to the background, check your email, bring the compile back, and do all of this without opening a second terminal.

When you press Ctrl+Z, the shell sends SIGTSTP to the foreground process, which pauses it immediately (state changes to T). The process is now a 'stopped job'. bg resumes it in the background (sends SIGCONT). fg brings any background or stopped job back to the foreground. The jobs command lists everything the current shell is managing.

The critical thing most developers miss is that background jobs in a terminal session are tied to that terminal. Close the terminal (or SSH connection drops), and the shell sends SIGHUP to all its jobs, which kills them. This is why nohup and disown exist — nohup makes a process immune to SIGHUP, and disown removes a job from the shell's job table so closing the terminal doesn't affect it.

For anything that needs to truly survive a disconnection, use tmux or screen — they create a persistent session that lives on the server, not inside your SSH connection.

#!/usr/bin/env bash
# job_control_workflow.sh
# Goal: Show the complete job control lifecycle including background survival

# --- Part 1: Basic job management ---
echo "=== Starting three background jobs ==="

# Simulate three different long-running tasks
sleep 120 &   # Pretend this is a database backup
backup_pid=$!
echo "Backup job started — PID: $backup_pid, Job: $!"

sleep 240 &   # Pretend this is a data export
export_pid=$!
echo "Export job started — PID: $export_pid"

sleep 360 &   # Pretend this is a log archive
archive_pid=$!
echo "Archive job started — PID: $archive_pid"

echo ""
echo "=== All current jobs in this shell ==="
jobs -l   # -l includes PIDs alongside job numbers

echo ""
echo "=== Suspending the export job (simulating Ctrl+Z) ==="
kill -SIGTSTP "$export_pid"   # Same signal as pressing Ctrl+Z interactively
sleep 0.2

echo "Job state after SIGTSTP:"
jobs -l   # Export should now show as 'Stopped'

echo ""
echo "=== Resuming export in the background ==="
bg %2    # %2 refers to job number 2 (the export). bg sends SIGCONT
sleep 0.2
jobs -l  # Should be back to Running

echo ""
# --- Part 2: Making a job survive terminal closure ---
echo "=== Running a job that survives SSH disconnection ==="

# nohup redirects stdout/stderr to nohup.out and makes process immune to SIGHUP
nohup sleep 9999 > /tmp/persistent_job.log 2>&1 &
persistent_pid=$!
echo "Persistent job PID: $persistent_pid"

# disown removes it from shell job table — terminal closing won't affect it
disown "$persistent_pid"
echo "Job $persistent_pid disowned — it will survive terminal closure"

# Verify it's no longer in the job table
echo ""
echo "Current jobs (persistent_pid should NOT appear):"
jobs -l

echo ""
echo "But it IS still in the process table:"
ps -p "$persistent_pid" -o pid,stat,cmd

# --- Cleanup ---
kill "$backup_pid" "$export_pid" "$archive_pid" "$persistent_pid" 2>/dev/null
wait 2>/dev/null
echo ""
echo "All jobs cleaned up."

Debugging Running Processes with strace and ltrace

When a process is misbehaving — high CPU, hanging, slow responses — the first question is 'what is it actually doing right now?' strace gives you the answer by intercepting system calls: every open, read, write, connect, poll that the process makes. ltrace does the same for library calls (e.g., malloc, free, gettimeofday).

Common debugging scenarios: A web server that's slow — strace -p <PID> -e trace=network reveals it's stuck on a connect() to a backend that's not responding. A process consuming 100% CPU — strace -c -p <PID> shows the distribution of syscall counts; if you see millions of gettimeofday() calls, your code is polling in a tight loop. A process that's leaking memory — strace -e trace=brk,mmap,munmap -p <PID> shows every heap allocation and deallocation.

strace can also attach to already-running processes, follow child processes (-f), and filter by specific syscalls (-e). Use it sparingly in production because it slows the traced process significantly (often 10-100x slower syscalls). For quick checks, strace -p <PID> -c for a summary, then dive deeper if needed.

ltrace is less common but useful when you suspect a library call is the bottleneck — for example, a process that calls gettimeofday millions of times or does excessive memory allocation.

#!/usr/bin/env bash
# strace_debug_demo.sh
# Goal: Use strace to diagnose process behavior without modifying the process

# Simulate a problematic process: a tight loop calling gettimeofday()
cat > /tmp/busy_loop.py << 'PYTHON'
import time
import sys
while True:
    time.time()  # calls gettimeofday syscall
    if time.time() % 1000 < 0.001:
        print("tick")
PYTHON

python3 /tmp/busy_loop.py &
busy_pid=$!
sleep 0.5  # Let it start

echo "=== strace summary for PID $busy_pid (10 seconds) ==="
strace -p "$busy_pid" -c -S time 2>&1 &
strace_pid=$!
sleep 3
kill "$strace_pid" 2>/dev/null
wait "$strace_pid" 2>/dev/null

echo ""
echo "=== Showing last 10 syscalls for PID $busy_pid ==="
strace -p "$busy_pid" -e trace=write -c -S calls 2>&1 &
strace_pid2=$!
sleep 2
kill "$strace_pid2" 2>/dev/null
wait "$strace_pid2" 2>/dev/null

echo ""
echo "=== Killing the test process ==="
kill "$busy_pid" 2>/dev/null
wait "$busy_pid" 2>/dev/null
echo "Done."

CPU Throttling, Memory Pressure and OOM — When Your Process Starves

Process management isn't just about starting and stopping things. It's about what happens when the system runs out of juice. You can have a process running with a pristine PID, responsive to signals, and still fail because the kernel decides it's eating too much.

The OOM killer is not your friend. It's the kernel's last resort when memory pressure hits the wall. It picks a victim based on a badness score — usually the process that leaks the most memory relative to its importance. If you don't set /proc/[pid]/oom_adj, your critical Postgres process looks just as killable as a rogue Python script.

CPU throttling is subtler. top shows %CPU, but that's a snapshot. The real story is in /proc/[pid]/sched — look for nr_switches and se.statistics.nr_throttled. When your process is voluntarily sleeping because the scheduler has had enough, you get latency, not crashes.

Memory pressure shows up as swap usage. vmstat 1 tells you si and so — swap in and swap out. If those numbers are non-zero, your process is paging. That's a 100x slowdown on every access. Fix the leak, don't tune the kernel.

// io.thecodeforge — devops tutorial

- name: Check OOM status for critical process
  hosts: production_db
  tasks:
    - name: Read oom_score and oom_adj for postgres
      shell: |
        PG_PID=$(pgrep -u postgres -f 'postgres: writer' | head -1)
        echo "PID: $PG_PID"
        cat /proc/$PG_PID/oom_score
        cat /proc/$PG_PID/oom_adj
      register: oom_data
    
    - name: Check memory pressure via vmstat
      shell: vmstat 1 3 | tail -1 | awk '{print "si="$7 " so="$8}'
      register: swap_activity
    
    - debug:
        msg: "{{ oom_data.stdout_lines }} | {{ swap_activity.stdout }}"

Resource Limits and cgroups — The Real Fences for Process Behavior

ulimit -a is the first thing you check when a process mysteriously crashes after running for three weeks. Open file handles, stack size, core dumps — these aren't configuration options, they're hard walls your process will smash into.

By default, ulimit -n (open files) is often 1024. A busy Nginx or Elasticsearch instance will eat through that in minutes under load. The crash log won't say "too many open files" — it'll show a vague socket() failure. You debug for hours. I've been there.

Systemd process managers let you set limits via LimitNOFILE=65536 in unit files. But that's per-service. For containers, you need cgroups v2 — memory.max, cpu.max, pids.max. The kernel enforces these at the group level, not the process level. A single runaway fork bomb in a container won't take down the host.

Check /sys/fs/cgroup/<slice>/ for your process's limits. If memory.current is within 90% of memory.max, you're about to lose that process. The kernel won't warn you — it will just kill it with SIGKILL. No cleanup, no signal handler, just dead.

// io.thecodeforge — devops tutorial

- name: Audit cgroup limits for running services
  hosts: all_workers
  tasks:
    - name: Get systemd slice for nginx
      shell: |
        systemctl show nginx | grep -i 'ControlGroup=' | awk -F'/' '{print $NF}'
      register: cgroup_slice
    
    - name: Read memory limits from cgroup
      shell: |
        CGROUP="/sys/fs/cgroup/{{ cgroup_slice.stdout }}"
        echo "memory.max: $(cat $CGROUP/memory.max 2>/dev/null || echo unlimited)"
        echo "memory.current: $(cat $CGROUP/memory.current)"
        echo "pids.max: $(cat $CGROUP/pids.max)"
      register: cgroup_info
    
    - debug:
        msg: "{{ cgroup_info.stdout_lines }}"

History Is Your True CLI Log — Stop Hunting Through Old Commands

Your terminal history is the most underrated investigation tool when a process goes sideways. Every command you ran left a timestamped trail in ~/.bash_history (or ~/.zsh_history). When a service died at 03:14, you can answer what you (or your automation) ran leading up to it.

history shows numbered entries. Pipe to grep to find relevant commands. !123 re-runs entry 123. But production intelligence comes from HISTTIMEFORMAT="%F %T " — add that to .bashrc and every entry gets a timestamp. Now your history becomes an audit log.

The trap: default history stores 500–1000 lines. That's useless after a week of heavy work. Set HISTSIZE=10000 and HISTFILESIZE=20000. And stop clearing history under pressure — that's exactly when you need it.

// io.thecodeforge — devops tutorial

# ~/.bashrc additions for production-grade history
HISTSIZE=10000
HISTFILESIZE=20000
HISTTIMEFORMAT="%F %T "
HISTCONTROL=ignoredups:erasedups
# Append to history file, don't overwrite
shopt -s histappend
# Record every command immediately
PROMPT_COMMAND="history -a; $PROMPT_COMMAND"

uname — The One Command Every Senior Runs Before Touching a Server

Before you deploy a binary, apply a kernel patch, or debug a syscall failure, you need the kernel version. uname -a gives you the full picture: kernel release, architecture, hostname, and build date. You don't guess if you're on x86_64 or aarch64 — you check.

uname -r returns just the kernel version. That matters when you're reading strace output and a syscall behaves differently across kernels. Docker containers inherit the host kernel, so uname inside a container tells you the host kernel, not the container's OS version. New engineers get burned by this constantly.

For process management specifically: OOM killer behavior, cgroup v1 vs v2 support, and seccomp profiles all tie to kernel version. Running uname -r should be muscle memory before any serious debugging session. It's the first diagnostic step, never the last.

// io.thecodeforge — devops tutorial

# Before deploying, always:
$ uname -a
Linux deploy-node-01 5.15.0-86-generic #96-Ubuntu SMP x86_64 GNU/Linux

# Kernel only:
$ uname -r
5.15.0-86-generic

# Architecture only:
$ uname -m
x86_64

# Useful in scripts:
ARCH=$(uname -m)
KERNEL=$(uname -r | cut -d. -f1-2)

curl Isn't for Downloads — It's Your Process-to-Service Probe

Every engineer knows curl fetches URLs. Senior engineers use curl to test process health, response time, and connectivity without leaving the terminal. When your process is supposed to serve HTTP on port 8080, curl -s -o /dev/null -w "%{http_code}:%{time_total} " http://localhost:8080/health tells you status code and response time in one shot.

curl -o saves output to a file. But the real power is in flags for diagnostics: -v shows the full handshake, -I returns headers only (no body — fast health check), -m 5 enforces a 5-second timeout so a stuck process doesn't hang your script. Combine them: curl -sI -m 3 http://localhost:8080/.

Production pattern: use curl --fail --silent --show-error in cron health checks. If the process is down, curl returns non-zero exit code and your monitoring fires. Stop checking logs to see if a service is alive — ask the port directly.

// io.thecodeforge — devops tutorial

# Real health probe for a process on :8080
$ curl -s -o /dev/null -w "Status: %{http_code}, Time: %{time_total}s\n" \
  --connect-timeout 3 --max-time 5 \
  http://localhost:8080/health

# Output if healthy:
Status: 200, Time: 0.042s

# In a monitoring script:
if ! curl --fail -s -o /dev/null http://localhost:8080/; then
  echo "Process unhealthy at $(date)" | systemd-cat -t healthcheck
  systemctl restart my-service
fi

Why /proc Is the Real-Time Process Database You're Ignoring

Every running process exposes its soul in /proc. This virtual filesystem contains per-PID directories packed with live data: command-line arguments in cmdline, environment variables in environ, file descriptors in fd, memory maps in maps, and current status in status. Reading /proc/PID/status gives you state, memory usage, and UID without spawning a new process. The real power comes from /proc/PID/fd — you can see every open file, socket, and pipe. Use lsof on a PID or read /proc/PID/limits to view resource soft/hard caps. Senior engineers use /proc to detect file descriptor leaks, stalled I/O (check wchan), and zombie children. No external tool is faster. Stop grepping logs; start reading filesystem truth.

// io.thecodeforge — devops tutorial

# Dump PID 1234's open file descriptors
ls -la /proc/1234/fd/

# Read current resource limits for PID 1234
cat /proc/1234/limits | grep -E '(open files|Max processes)'

# Check why a process is sleeping (kernel wait channel)
cat /proc/1234/wchan

# Stream memory maps for leak analysis
cat /proc/1234/smaps | grep -E '(Pss|Rss)'

Why Zombie Processes Stall Your Cleanup (and How Orphans Differ)

A zombie process is a dead child whose parent hasn't called wait() to read its exit code. The kernel keeps the PID entry until the parent acknowledges death. Zombies show as 'defunct' in ps — they hold no memory or CPU, but they consume a PID slot. Your system's max PID limit (cat /proc/sys/kernel/pid_max) caps at 32768 by default. Exhaustion means no new processes can spawn. Orphan processes are different: the parent died first, so init (PID 1) adopts them. Orphans run normally and eventually get reaped by init. To fix zombies, kill the parent (it can't report death of children if hung). Use waitpid() in code or strace -e wait4 to diagnose. Never let zombies accumulate; they silently rot your process table.

// io.thecodeforge — devops tutorial

# Find zombie processes
ps aux | awk '{if ($8 == "Z") print $2, $11}'

# Count current zombies
ps -eo state | grep -c Z

# Check PID table utilization
echo "Max PIDs: $(cat /proc/sys/kernel/pid_max)"
echo "Used PIDs: $(ps -e | wc -l)"

# Kill parent of zombie to trigger reaping
# Replace 1234 with zombie PID
# ps -o ppid= -p 1234 | xargs kill -9