Processes, Signals & Services

What is it?

A process is a running program with a PID; signals (TERM, KILL, HUP) control it. A service is a long-running process managed by systemd so it starts at boot and restarts on failure.

Why it matters

Most operational work is about processes and services: is it running, why did it stop, how do I restart it cleanly? systemd is the control panel for all of it.

Where you see it

`ps`/`top` list processes, `kill -TERM pid` asks one to stop, `systemctl status/start/stop/restart nginx` manages a service.

What normal looks like

Services show 'active (running)' with a recent start time and no restart loop; CPU/memory are within expectations.

What suspicious looks like

A service 'failed' or flapping (restarting every few seconds), or a runaway process pinning the CPU — both point to a config or resource problem.

How analysts investigate

Start with `systemctl status <svc>` (state + last logs), then `journalctl -u <svc>` for why it failed; use signals deliberately (TERM to stop cleanly, KILL only as a last resort).

Common beginner mistakes

Reaching for kill -9 (KILL) first, giving the process no chance to clean up.
Restarting a failed service without reading why it failed.

Running, stopped, or flapping

  systemctl status nginx
    Active: failed (Result: exit-code)   ← not running
  journalctl -u nginx --since -5m
    nginx: [emerg] bind() to 0.0.0.0:80 failed (Address already in use)
  → another process holds :80; find and stop it, then restart

systemctl shows state; journalctl -u explains WHY — read the reason before restarting.

Quick check

A service is 'failed'. What is the best first step?

A quick self-check — it doesn't affect your XP or progress.