systemd: the thing that keeps your service running
systemd is the service manager on most Linux systems: the process that starts at boot and is responsible for launching, supervising and restarting the long-running services you depend on. You describe a service in a unit file, and systemd keeps it running, restarts it if it dies, and captures its logs.
At a glance
What it is
The Linux manager that starts and supervises long-running services
How you use it
Write a unit file, then enable and start it with systemctl
Why it matters
It restarts a crashed service and brings it back after a reboot
Where the logs go
Into the journal, read with journalctl
Flow
How a service stays up under systemd
systemd reads the unit file at boot, starts the service, and watches it. If the process dies it starts again. The green step is the running service you rely on.
1
Unit fileyou describe how to start the service
2
systemd starts and watches itat boot, and after any crash
3
Service stays runningrestarted automatically when it dies
What does systemd do?
systemd is the first process Linux starts at boot, and from there it is in charge
of everything that has to keep running: your web server, your proxy, your
inference server. You hand it a small text file, the unit file, that says how to
start the service and what it needs first. systemd starts it, watches it, and if
the process dies it starts it again. After a reboot it brings the whole set back
up in the right order without you touching a keyboard.
That last part is the reason it matters for self-hosting. A service you started
by hand in a terminal is gone the moment the machine reboots or the process
crashes. A service under systemd comes back. The difference between a hobby setup
and one you can leave alone is usually just whether systemd is managing it.
How does it fit with containers?
The two are not rivals. A container packages a service and its dependencies;
systemd makes sure that container, or a plain process, actually starts and stays
up on the host. A common pattern is a systemd unit whose job is to launch a
container and restart it if it stops. Containers handle “what does this service
need to run”; systemd handles “is it running, and if not, why not”. You read its
answer with journalctl, which holds the logs of every service it supervises, so
when something is down the first question, what does the journal say, has one
place to look.
Check it yourself
systemctl status sshd
Shows whether the service is active, when it last started, and its recent log lines. Swap sshd for any unit you run.
systemd is good for
Starting a service at boot without manual intervention
Restarting a service automatically when it crashes
Holding back a service until what it depends on is ready
Collecting a service's logs in one place you can query
systemd will not
Package a service's dependencies; that is a container's job
Fix a service that crashes on purpose; it just restarts the loop
Run inside most containers, which ship without an init by design
Make a misconfigured unit start; a typo means it silently does nothing