Console9

systemd (systemctl / journalctl)

Manage services, timers, and logs on Linux with systemd, systemctl, and journalctl.

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 TypeExtensionPurpose
Service.serviceManages a daemon or one-shot process.
Timer.timerSchedules a service to run at intervals or calendar times, replacing cron.
Socket.socketCreates a listening socket; starts the matching service on first connection.
Target.targetGroups units into synchronization points (similar to SysVinit runlevels).
Mount.mountControls filesystem mount points.
Path.pathMonitors 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.service

The .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.service

Combine both actions — enable and start a service in one command:

sudo systemctl enable --now nginx.service

How 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.2M

How 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 -f

View kernel messages only:

journalctl -k

How 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.target

After creating the file, reload systemd's configuration and start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

How 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.sh

Create /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.target

Enable the timer (not the service):

sudo systemctl enable --now backup.timer

List all active timers:

systemctl list-timers --all

How 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-reload

Without daemon-reload, systemd uses the old in-memory configuration.

systemd Troubleshooting

Error / SymptomCauseFix
Failed to start {service}Misconfigured unit file or missing binary→ Full article
Job for {service} failed because the control process exited with error codeService crashes on startup→ Full article
A dependency job for {service} failedA required dependency unit is not available→ Full article
Service starts but exits immediatelyWrong Type= directive or foreground/background mismatch→ Full article
systemctl status shows inactive (dead)Service is not enabled or was stopped→ Full article

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.