systemctl: Service Management

A service is a program that runs in the background — a web server, a database, an SSH daemon. Unlike the commands you type, nobody is sitting at a terminal to launch these. Someone has to start them at the right time, in the right order, restart them if they crash, and bring them back after a reboot.

That someone is systemd, the first process Linux starts at boot (PID 1 — run ps -p 1 and there it is). Think of systemd as an air-traffic controller for your machine: every background program is an aircraft, and systemd decides what takes off, in what order, and what gets cleared to fly again after the airport reopens (a reboot).

systemd describes each thing it manages as a unit. The type you'll meet first is the service unit, written name.service — for example nginx.service (the .service suffix is optional when typing; nginx works). There are other unit types — timers, mount points, targets — but services are the daily bread. You talk to systemd through one command: systemctl.

One idea underpins this whole lesson, so meet it before any command: a service has two completely independent states.

• Is it running right now? — the runtime state (active / inactive).
• Will it start itself at the next boot? — the boot state (enabled / disabled).

Every combination is possible: running-but-disabled (works until the next reboot, then silently gone), stopped-but-enabled (down now, will return at boot), and so on. Most real-world service confusion — and most graded-lab point losses — comes from checking one of these states and assuming it implies the other. It never does.

The golden rule of operations: look before you leap. Before you restart anything — especially on a machine you share with other admins or graders — establish what state it's in now. systemctl status is the full report; it answers both of the two questions at once, if you know which words to read.

The full status report is for humans. In scripts — and for quick checks — you want a one-word answer, and systemctl has a dedicated question for each state:

Now the verbs that change things. This family acts immediately, on the currently-running system — and none of them touch what happens at the next boot. That's not a limitation; it's a design you can lean on: you can bounce a service all day during debugging without accidentally changing its boot behaviour.

enable is the other half of the story — the boot state. It's worth knowing what it physically does, because then the behaviour stops being magic: enable creates a symlink in a directory systemd walks at boot. When boot reaches the multi-user stage, systemd starts everything linked into multi-user.target.wants/. That symlink IS the persistence — you can literally ls it.

And here's the symmetry that surprises people: just as start doesn't touch boot state, `enable` doesn't touch runtime state. Enable a stopped service and it stays stopped until the next boot. Since you almost always want both — running now AND at every boot — systemd provides a combined form.

Sooner or later, start fails — a typo in a config file, a port already taken, a missing directory. The reflex to train: the error message systemctl prints is only the headline; the story is in the journal. systemd captures everything a service writes (its stdout, stderr, and log messages) into a central log — the journal — and journalctl -u <unit> replays exactly one service's slice of it.

Sometimes the service never gets far enough to log anything, because the unit file itself is wrong: a misspelled directive, an ExecStart that points at nothing. systemd doesn't refuse a misspelled key; it logs a warning and ignores the line, so Reztart=on-failure silently means no restart policy at all. systemd-analyze verify reads a unit file (and its drop-ins) and reports those problems without starting anything:

You have a real root shell. Take nginx through the complete lifecycle — baseline, make-permanent, verify, and the two-states check — saying each state transition out loud as you cause it. This is the exact sequence a graded "configure a service" task wants, and the verify step is the habit that earns the points.

Two box realities to expect. `nginx` may not be installed yet — on the RHEL lab base, sudo dnf install -y nginx first (the exercise is the lifecycle, not the daemon). And `journalctl -u nginx` may be empty, because this host doesn't run journald — systemctl status nginx shows the recent lines inline, and flat logs live under /var/log. The enable/start/is-enabled/is-active steps — the ones a graded task checks — work here.