Processes & Services

A process is a running instance of a program, and every process has a unique Process ID (PID) assigned by the kernel, plus a Parent Process ID (PPID) identifying which process started it. PID 1 is always the first process the kernel starts at boot — on virtually all modern distributions, that's `systemd`, which then starts every other process, directly or indirectly, making every process on the system a descendant of PID 1.

A process moves through states over its lifetime: Running (actively executing or ready to), Sleeping (waiting for something — input, a timer, a lock — the most common state for an idle process), Stopped (paused, typically by a signal, resumable), and Zombie (the process has finished executing but its parent hasn't yet collected its exit status — a genuine zombie is harmless in small numbers but indicates the parent process has a bug if they accumulate). An orphan process is one whose parent exited first; it gets automatically re-parented to PID 1 (or a subreaper) so it isn't left dangling.

`ps` gives a snapshot of processes at the moment you run it; `top` (or the friendlier `htop`, often installed separately) gives a live, continuously updating view sorted by resource usage — your default tool for "what is actually using CPU/memory right now on this box".

`kill` doesn't inherently mean "terminate" — it sends a signal to a process, and different signals request different behavior. `SIGTERM` (signal 15, the default `kill` sends) politely asks a process to shut down, giving it a chance to close files, save state, and exit cleanly — a well-written program handles SIGTERM by cleaning up before exiting. `SIGKILL` (signal 9) is not a request; the kernel terminates the process immediately with no chance for cleanup, which is why it's a last resort for a process that's truly stuck and not responding to SIGTERM, not a routine default.

`SIGHUP` (signal 1) is used by many services as a signal to reload their configuration without fully restarting — this predates systemd, from an era when a terminal hangup literally sent this signal to processes attached to it. `SIGSTOP` pauses a process (not gracefully cancelable by the process itself, unlike SIGTERM) and `SIGCONT` resumes it — this is how job control works under the hood.

Job control lets you manage multiple processes within one shell session: `command &` starts a command in the background immediately; `Ctrl+Z` suspends a running foreground command; `bg` resumes a suspended job in the background; `fg` brings a background or suspended job back to the foreground; `jobs` lists what's running in the current session. `nohup command &` goes a step further — it starts a command in the background that will keep running even after you log out and your shell session ends, which plain `&` alone does not guarantee.

systemd manages services as "units" — most commonly `.service` units, though timer, socket, and mount units also exist. `systemctl status <name>` is the single most useful diagnostic command on a modern Linux system: it shows whether a service is running, its recent log output, its PID, and its enabled/disabled state, all in one view. `systemctl start/stop/restart <name>` control a service immediately for the current boot; `systemctl enable/disable <name>` control whether it starts automatically on future boots — these are independent: a service can be running now but not enabled for next boot, or enabled for next boot but not currently running.

`journalctl` reads systemd's centralized logging (the journal), which captures both systemd's own messages and anything a service writes to standard output/error. `journalctl -u <service-name>` filters to just that service's logs — almost always your first move after `systemctl status` shows a problem. `journalctl -f` follows the log live, like `tail -f` for the entire system journal, and `journalctl --since "10 minutes ago"` scopes to a time window, which is invaluable when correlating a service failure with a specific incident time.

Writing your own unit file is how you turn any script or long-running program into a properly managed service: a `.service` file placed in `/etc/systemd/system/` defines what to run (`ExecStart`), when to start it relative to other units (`After`, `Wants`), and how to handle it exiting (`Restart=on-failure` is a common, genuinely useful setting that makes systemd automatically restart a crashed service). After creating or editing a unit file, `systemctl daemon-reload` is required to make systemd re-read it before `start`/`enable` will pick up the change — a step that's easy to forget and produces confusing "nothing happened" results if skipped.