Runtime state versus boot configuration
Systemd manages daemons as units. systemctl start nginx changes runtime state immediately but does not configure the next boot. systemctl enable nginx creates boot-time links but normally does not start now; systemctl enable --now nginx performs both. disable removes the boot links, and mask blocks a unit from being started at all, even by another service.
reload asks a service to reread configuration without stopping when the unit supports it; restart stops and starts it, causing a brief interruption.
| Command | Answers |
|---|---|
systemctl status nginx |
State, main PID, and the latest log lines |
systemctl is-active nginx |
Running right now? |
systemctl is-enabled nginx |
Starts at boot? |
systemctl list-units --type=service |
Loaded services |
systemctl --failed |
Units that failed |
flowchart LR U["Unit file<br/>nginx.service"] -- "daemon-reload" --> SD["systemd<br/>PID 1"] SD -- "start" --> RUN["Running now<br/>is-active"] SD -- "enable" --> BOOT["Starts at boot<br/>is-enabled"] RUN --> J["journalctl -u nginx<br/>logs"] %% step U: A unit file describes how to run the service; your own go in /etc/systemd/system. %% step SD: After editing a unit, daemon-reload makes systemd read it again. %% step RUN: start changes the state right now but says nothing about the next boot. %% step BOOT: enable creates the boot-time links; enable --now does both. %% step J: Check the result in the journal, not only in the editor.
Unit files
A unit file describes how to run something. Packages install them under /lib/systemd/system/ (or /usr/lib/systemd/system/); your own units and overrides belong in /etc/systemd/system/, which takes priority.
[Unit]
Description=Demo web app
After=network.target
[Service]
ExecStart=/opt/demo/bin/server
Restart=on-failure
User=demo
[Install]
WantedBy=multi-user.target
After creating or editing a unit, run sudo systemctl daemon-reload so systemd rereads it. systemctl edit nginx creates an override file instead of changing the packaged unit, so upgrades do not erase your change.
Logs with journalctl
Systemd collects service output in the journal. journalctl -u nginx shows one unit's log, -f follows new lines, --since "1 hour ago" narrows the time, and -p err keeps only errors. After a configuration change, verify with systemctl status and logs rather than trusting only the editor's exit code.
Targets and older tools
Targets group units into system states: multi-user.target is a normal server, graphical.target adds a desktop. SysV used service, chkconfig, and runlevels. Runlevel 0 means halt and 6 means reboot; systemd maps the ideas to targets. Older commands may remain as wrappers, but systemctl is the modern interface.
Many operations require root, so leading sudo is normal. Inside a root shell, omitting sudo does not change the systemctl operation.