systemd (systemctl / journalctl)
Manage services, timers, and logs on Linux with systemd, systemctl, and journalctl.
- systemd (systemctl / journalctl)
- What systemd Does and When to Use It
- How to Install systemd
- Core Concepts of systemd
- systemd Unit Files
- systemd Unit Types
- systemd Service States
- systemd Dependency Management
- systemd Journal and journalctl
- Common Tasks with systemd
- How to Start, Stop, and Restart a Service with systemctl
- How to Enable or Disable a Service at Boot with systemctl
- How to Check Service Status with systemctl
- How to View Logs with journalctl
- How to Create a Custom systemd Service Unit
- How to Use systemd Timers Instead of Cron
- How to Reload systemd After Editing Unit Files
- systemd Troubleshooting
- Related Tools and Guides
systemd (systemctl / journalctl)
systemd is the init system and service manager that controls how Linux starts, stops, and supervises processes on Ubuntu, Debian, RHEL, Fedora, Arch Linux, and most modern distributions.
What systemd Does and When to Use It
systemd initializes the Linux operating system after the kernel finishes booting. It starts services in parallel, manages dependencies between them, and tracks every spawned process through control groups (cgroups). The two primary commands for interacting with systemd are
systemctl (service control) and
journalctl (log queries).
systemd replaces the older SysVinit and Upstart init systems. Unlike SysVinit — which executed shell scripts sequentially — systemd uses declarative unit files that describe the desired state of a service. This declarative approach enables parallel startup, on-demand socket activation, and integrated resource management.
systemd is not a single binary. It is a suite of daemons and utilities:
systemd (PID 1),
systemctl,
journalctl,
systemd-analyze,
systemd-resolve,
timedatectl,
hostnamectl, and others. For official documentation, see
freedesktop.org/software/systemd.
How to Install systemd
systemd ships by default on all major Linux distributions released after 2015. No installation step is necessary on Ubuntu 16.04+, Debian 8+, RHEL 7+, Fedora 15+, or Arch Linux.
Verify the installed version of systemd:
systemctl --version
systemd 255 (255.4-1ubuntu8)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP ...Core Concepts of systemd
systemd Unit Files
A systemd unit file is a plain-text configuration file that defines a resource the system manages. Unit files follow INI-style syntax with sections like
[Unit],
[Service], and
[Install]. systemd loads unit files from three directories, listed from lowest to highest precedence:
/usr/lib/systemd/system/— units installed by packages./run/systemd/system/— runtime units, removed on reboot./etc/systemd/system/— units created or customized by the administrator (highest priority).
systemd Unit Types
systemd supports 11 unit types, each identified by a file extension. The most common types for system administrators are:
| Unit Type | Extension | Purpose |
|---|---|---|
| Service | .service | Manages a daemon or one-shot process. |
| Timer | .timer | Schedules a service to run at intervals or calendar times, replacing cron. |
| Socket | .socket | Creates a listening socket; starts the matching service on first connection. |
| Target | .target | Groups units into synchronization points (similar to SysVinit runlevels). |
| Mount | .mount | Controls filesystem mount points. |
| Path | .path | Monitors a file or directory and activates a service when changes occur. |
systemd Service States
Every systemd unit exists in one of several states. The
systemctl status command reports both a high-level state (active, inactive, failed) and a sub-state (running, exited, dead, waiting). A service marked
enabled starts automatically at boot; a service marked
disabled does not start at boot but can still be started manually with
systemctl start.
systemd Dependency Management
systemd manages dependencies between units through directives in the
[Unit] section of the unit file.
Wants= creates a weak dependency — systemd tries to start the wanted unit but continues if it fails.
Requires= creates a hard dependency — if the required unit fails, the dependent unit also stops.
After= and
Before= control ordering without creating dependencies.
systemd Journal and journalctl
systemd collects log messages from all services, the kernel, and the boot process into a binary journal stored under
/var/log/journal/ (persistent) or
/run/log/journal/ (volatile). The
journalctl command queries this journal. The journal replaces traditional syslog for most use cases, though systemd can forward messages to rsyslog if configured.
Common Tasks with systemd
How to Start, Stop, and Restart a Service with systemctl
systemctl controls the runtime state of systemd services. Use
start to launch a stopped service,
stop to terminate a running service, and
restart to stop and immediately start a service:
sudo systemctl start nginx.service
sudo systemctl stop nginx.service
sudo systemctl restart nginx.serviceThe
.service suffix is optional —
systemctl restart nginx works the same way.
How to Enable or Disable a Service at Boot with systemctl
systemctl
enable creates a symlink so systemd starts the service automatically at boot.
disable removes that symlink. These commands do not start or stop the service immediately:
sudo systemctl enable nginx.service
sudo systemctl disable nginx.serviceCombine both actions — enable and start a service in one command:
sudo systemctl enable --now nginx.serviceHow to Check Service Status with systemctl
systemctl status displays the current state, PID, memory usage, and recent log lines for a service:
systemctl status nginx.service
● nginx.service - A high performance web server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
Active: active (running) since Mon 2026-03-30 10:15:22 UTC; 2h ago
Main PID: 1234 (nginx)
Tasks: 3 (limit: 4915)
Memory: 8.2MHow to View Logs with journalctl
journalctl displays systemd journal entries. Filter logs by service with
-u, follow live output with
-f, and limit by time with
--since:
journalctl -u nginx.service
journalctl -u nginx.service --since "1 hour ago"
journalctl -u nginx.service -fView kernel messages only:
journalctl -kHow to Create a Custom systemd Service Unit
Create a new unit file under
/etc/systemd/system/ to define a custom service. The file requires three sections —
[Unit],
[Service], and
[Install]:
[Unit]
Description=My Custom App
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.yaml
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetAfter creating the file, reload systemd's configuration and start the service:
sudo systemctl daemon-reload
sudo systemctl enable --now myapp.serviceHow to Use systemd Timers Instead of Cron
systemd timers replace cron jobs with better logging, dependency management, and randomized delay support. A timer requires two files — a
.timer unit and a matching
.service unit.
Create
/etc/systemd/system/backup.service:
[Unit]
Description=Daily backup script
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.shCreate
/etc/systemd/system/backup.timer:
[Unit]
Description=Run backup daily at 2:00 AM
[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=15min
[Install]
WantedBy=timers.targetEnable the timer (not the service):
sudo systemctl enable --now backup.timerList all active timers:
systemctl list-timers --allHow to Reload systemd After Editing Unit Files
After creating or modifying any unit file, run
daemon-reload to make systemd re-read configurations from disk:
sudo systemctl daemon-reloadWithout
daemon-reload, systemd uses the old in-memory configuration.
systemd Troubleshooting
| Error / Symptom | Cause | Fix |
|---|---|---|
Failed to start {service} | Misconfigured unit file or missing binary | → Full article |
Job for {service} failed because the control process exited with error code | Service crashes on startup | → Full article |
A dependency job for {service} failed | A required dependency unit is not available | → Full article |
| Service starts but exits immediately | Wrong
Type= directive or foreground/background mismatch | → Full article |
systemctl status shows
inactive (dead) | Service is not enabled or was stopped | → Full article |
Related Tools and Guides
Crontab schedules recurring commands using the traditional cron daemon. systemd timers provide an alternative with better logging and dependency support. See the Crontab article.
Logrotate relies on cron or systemd timers to trigger log rotation at scheduled intervals. See the Logrotate article.
SSH runs as a systemd service (
sshd.service) on modern Linux distributions. See the
SSH article.
Docker containers run as systemd services when managed by the Docker daemon. See the Docker article.