Processes, signals and services

A running program is a process, and on a server you are constantly asking: what is running, is it using too much CPU or memory, why did it stop, and how do I start it again so it stays up? Managing processes and the services that keep them running is core operations work — when an app "goes down", you are almost always looking at a process. This lesson is processes, the signals you send them, and the service manager that supervises them.

What a process is

When you run a program — a web server, a database, your app — the kernel creates a process: a running instance with its own memory, and a PID (process ID), a unique number. Everything running on the machine is a process, each with a PID, and you manage them by PID.

To see what is running:

ps aux              # a snapshot of all processes: user, PID, CPU%, memory%, command
ps aux | grep nginx # filter to just the ones mentioning nginx
top                 # a live, updating view of processes, sorted by CPU (q to quit)
htop                # a nicer top, if installed — colour, scrollable

ps aux gives you a one-off list; top/htop update live so you can watch which process is eating the CPU. When a server is slow, top is often your first move: it shows immediately whether one process is consuming everything.

Foreground, background and jobs

A command you run normally holds your terminal until it finishes — it runs in the foreground. Sometimes you want it to keep running while you carry on:

./long-task.sh          # runs in the foreground; your prompt is blocked until it ends
./long-task.sh &        # the & runs it in the background; you get your prompt back
jobs                    # list background jobs in this shell
fg                      # bring the last background job back to the foreground

Ctrl-C stops the foreground process; Ctrl-Z pauses it (then bg resumes it in the background). These matter when you are logged into a server and need to run something without tying up your session — though for anything that must stay running after you log out, you use a service (below), not &.

Signals: how you talk to a process

You control a running process by sending it a signal with kill — which, despite the name, is just "send a signal", not always "destroy":

kill 1234          # send the default TERM signal to PID 1234 — ask it to stop gracefully
kill -TERM 1234    # the same, explicit
kill -KILL 1234    # or kill -9 — force it to stop immediately, no cleanup
kill -HUP 1234     # HUP: often means "reload your config" for a server
pkill nginx        # signal processes by name instead of PID

The important distinction:

• TERM (kill) — politely asks the process to shut down: finish what it is doing, close files, exit cleanly. Try this first.
• KILL (kill -9) — the kernel destroys the process immediately; it gets no chance to clean up, which can leave things in a bad state (a half-written file, a stuck lock). Use only when TERM does not work.

Reaching straight for kill -9 is a bad habit — it is the sledgehammer. Ask nicely first (kill), and only force it if the process ignores you.

Services: processes that must stay running

A web server or database must run continuously, start automatically on boot, and restart if it crashes. You do not manage those with & — you manage them as services, and on modern Linux the service manager is systemd, driven by the systemctl command:

sudo systemctl start nginx      # start the nginx service now
sudo systemctl stop nginx       # stop it
sudo systemctl restart nginx    # stop then start (apply a change)
sudo systemctl reload nginx     # reload config without a full restart, if supported
sudo systemctl status nginx     # is it running? recent logs? — your first check
sudo systemctl enable nginx     # start automatically on boot
sudo systemctl disable nginx    # do not start on boot

systemctl status <service> is one of the most useful commands in operations: it tells you whether a service is active (running) or failed, when it started, and shows its most recent log lines — often enough to see why it is down. When someone says "the site is down", systemctl status on the web server is a natural first move.

The difference between start and enable catches everyone once: start runs it now; enable makes it run on the next boot. You usually want both — a service that runs now and comes back after a reboot.

Reading the logs of a service

systemd captures each service's logs, and you read them with journalctl:

journalctl -u nginx            # all logs for the nginx service
journalctl -u nginx -f         # follow them live (like tail -f)
journalctl -u nginx --since "10 min ago"

Between systemctl status (is it up? why did it fail?) and journalctl -u (the full logs), you can diagnose most "the service is down" situations — which is a large part of the operations job.

Check your work

A process is a running program with a PID. See them with ps aux (snapshot; | grep to filter) and top/htop (live, by CPU — first move when a server is slow).

Foreground/background: a command holds the terminal (foreground); & backgrounds it; jobs/fg/bg, Ctrl-C stops, Ctrl-Z pauses. For anything that must outlive your session, use a service, not &.

Signals via kill (send a signal, not always destroy): TERM (kill) asks it to stop gracefully — try first; KILL (kill -9) forces it, no cleanup — last resort; HUP often reloads config; pkill by name. Don't reach straight for -9.

Services (must stay running, start on boot, restart on crash) via systemd/systemctl: start/stop/ restart/reload, status (running? failed? recent logs — first check), enable/disable (on boot). start = now, enable = on boot — usually you want both.

Service logs: journalctl -u <service> (-f to follow, --since). status + journalctl -u diagnose most "service down" cases.

Practice

1. Run ps aux | grep for a program you have running; note its PID, CPU% and memory%.
2. Run top (or htop), watch it update, identify the top CPU consumer, and quit with q.
3. Start a long-running command in the background with &, list it with jobs, and bring it back with fg.
4. Explain the difference between kill (TERM) and kill -9 (KILL), and why you try TERM first.
5. On a system with systemd, run systemctl status on a service and read whether it is active, and its recent logs.
6. Explain the difference between systemctl start and systemctl enable, and why you usually want both.

Official documentation

• Ubuntu — Managing processes — Processes and process tools on a server.
• systemd — systemctl manual — Managing services.
• systemd — journalctl manual — Reading service logs.

Next: text processing with grep, sed, awk and pipes.