linux system-management

systemd

systemd linux init-system services
Plain English

systemd is the master control program that starts up a Linux system and keeps everything running. When you power on a Linux server, systemd is the first thing that loads, and it starts all the services in the right order: networking, the web server, the database, SSH. If a service crashes, systemd can automatically restart it. It is the tool you use to start, stop, enable, and check the status of services on modern Linux systems.

Technical Definition

systemd is a system and service manager for Linux, serving as PID 1 (the first process started by the kernel). It replaced SysVinit and Upstart as the default init system on most major distributions (Debian, Ubuntu, RHEL, Fedora, Arch, SUSE).

Core concepts:

  • Unit: the basic object systemd manages. Types include: service (.service), timer (.timer), mount (.mount), socket (.socket), target (.target), path (.path)
  • Target: a grouping of units (similar to SysVinit runlevels). multi-user.target = non-graphical multi-user, graphical.target = with GUI
  • Dependencies: units declare Requires, Wants, After, Before relationships for ordered startup
  • Cgroups integration: each service runs in its own cgroup for resource isolation and accounting

Service lifecycle:

  • systemctl start <unit>: start immediately
  • systemctl stop <unit>: stop immediately
  • systemctl restart <unit>: stop then start
  • systemctl reload <unit>: reload configuration without stopping (if supported)
  • systemctl enable <unit>: start automatically on boot
  • systemctl disable <unit>: do not start on boot
  • systemctl status <unit>: show current state, PID, recent logs

Key features:

  • Socket activation: start services on-demand when a connection arrives
  • Watchdog: automatically restart services that stop responding
  • Journal (journald): centralized binary logging with structured metadata
  • Resource limits: CPU, memory, and I/O limits per service via cgroup controls

systemd service management 

# Check service status
$ systemctl status nginx
● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
     Active: active (running) since Tue 2026-04-15 03:00:00 UTC
   Main PID: 1234 (nginx)
      Tasks: 5 (limit: 4915)
     Memory: 12.3M
     CGroup: /system.slice/nginx.service
             ├─1234 nginx: master process
             └─1235 nginx: worker process

# View recent logs for a service
$ journalctl -u nginx --since "1 hour ago" --no-pager

# Create a custom service
$ sudo cat > /etc/systemd/system/myapp.service << 'EOF'
[Unit]
Description=My Application
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target
EOF

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now myapp
In the Wild

systemd is how you manage services on any modern Linux server. Starting a web server, checking why a database failed, enabling a service to survive reboots, and reading application logs all go through systemd. In production, custom systemd unit files are the standard way to deploy long-running applications (Node.js servers, Python APIs, Go binaries) that are not containerized. The journalctl command is the primary tool for reading application logs. Docker and Kubernetes also run as systemd services on the host. When troubleshooting “the service will not start,” the workflow is: systemctl status <service> to see the state, then journalctl -u <service> -e to read the error logs. Understanding systemd is essential for any Linux administration role.

← Back to Dictionary