Few pieces of software have provoked as much resistance as systemd, and much of it came from engineers who knew the older init scripts well and disliked seeing a familiar system replaced by something larger and more opinionated. Setting the politics aside, systemd solved real problems that the old approach handled poorly, and since it is now the init system on nearly every major distribution, understanding it is no longer optional. It is the first userspace process, PID 1, and its job is to bring up the system and manage services, but it does so with a model quite different from the sequential shell scripts it replaced.
The central concept is the unit, a declarative description of something systemd manages, and the most common kind is the service unit, a plain text file that states how to start a program, when to start it, and what it depends on. This is the key departure from the old init scripts, which ran in a fixed sequence one after another. systemd instead reads the declared dependencies of every unit and starts services in parallel wherever their dependencies allow, which is a large part of why modern systems boot faster. A service unit names its dependencies, the conditions under which it should run, and what to do if it fails, and systemd resolves the whole graph rather than following a hand ordered list.
| COMMAND | WHAT IT DOES |
|---|---|
| systemctl start, stop | Start or stop a service immediately. |
| systemctl enable, disable | Set whether a service starts automatically at boot. |
| systemctl status | Show whether a service is running, with its recent log lines. |
| systemctl restart, reload | Restart a service, or reload its configuration without a full restart. |
| journalctl -u name | Show the collected logs for a specific unit. |
systemd also absorbed responsibilities that used to be separate, most visibly logging, through the journal, which collects the output of every service into a single indexed store queried with journalctl rather than scattered across text files under /var/log. This consolidation is exactly what its critics objected to, a single system reaching into many areas that were once independent, and that objection is not unreasonable. But the practical reality for anyone operating Linux today is that systemd is the interface through which services are started, supervised, and inspected, and time spent resisting it is better spent learning it, because a working command of units, dependencies, and journalctl is now simply part of what it means to administer a Linux system competently, whatever one thinks of how it came to be that way.