systemd and Services

Every long-running program on a Linux server - a web server, a database, a queue worker - needs something to start it at boot, restart it if it crashes, and collect its logs. That something is systemd, the init system used by nearly every major Linux distribution today (you saw why it won out over the older SysV init in the history lesson).

systemd is PID 1

When the kernel finishes booting, it starts exactly one process by hand: systemd, which always gets process ID 1. Every other process on the system is, directly or indirectly, a child of PID 1. systemd's job is to bring the rest of the system up in the right order and keep it running.

Units and services

systemd manages units - services, mount points, timers, sockets, and more - each described by a small configuration file. A service unit looks roughly like this:

[Unit]
Description=My web application

[Service]
ExecStart=/usr/bin/node /srv/app/server.js
Restart=on-failure

[Install]
WantedBy=multi-user.target

• [Unit] - metadata and dependencies (what must start before this).
• [Service] - how to start it, and what to do if it dies.
• [Install] - which boot target should pull this service in when it's enabled.

You won't need to write one of these files in this course, but recognizing the shape of a unit file will help the moment you open one on a real server.

systemctl: the one command that controls it all

systemctl start nginx        # start it right now
systemctl stop nginx         # stop it right now
systemctl restart nginx      # stop, then start
systemctl status nginx       # is it running? recent log lines?
systemctl enable nginx       # start it automatically on every future boot
systemctl disable nginx      # stop starting it automatically on boot
systemctl daemon-reload      # re-read unit files after editing one

start vs. enable - the distinction that trips everyone up

• start affects right now, this boot only.
• enable affects every future boot, by creating a symlink into a target like multi-user.target.wants/ - it does not start the service immediately.

That's why deploying a new service almost always means running both: systemctl enable myapp && systemctl start myapp.

Reading the logs: journalctl

systemd also owns centralized logging through journalctl, which replaces hunting through scattered files under /var/log:

journalctl -u nginx          # every log line from the nginx unit
journalctl -u nginx -f       # follow new lines live, like tail -f
journalctl -b                # everything logged since the last boot

The practice terminal simulates both systemctl and journalctl so you can practice the full workflow below - just keep in mind journalctl's log lines are generated on the spot rather than reflecting anything systemctl actually did, and -f can't truly stream new lines the way it does on a real system.

Try it

systemctl status nginx
systemctl enable nginx
systemctl start nginx
systemctl restart nginx
journalctl -u nginx
systemctl stop nginx
systemctl disable nginx

Further reading

• "How Linux Works" by Brian Ward (No Starch Press) - its systemd chapter explains unit files, targets, and dependency ordering from first principles.
• man systemd and man systemctl on any real Linux box - systemd ships extensive, accurate manual pages.