liminfoSystemd Reference
Free reference guide: Systemd Reference
About Systemd Reference
The Systemd Reference is a searchable quick-reference for systemd, the init system and service manager used by virtually all modern Linux distributions including Ubuntu, Fedora, Debian, RHEL, Arch, and SUSE. It covers eight categories: Unit File directives, Service configuration, Timer scheduling, Socket activation, journalctl log queries, systemctl commands, Target management, and Boot analysis. Each entry includes the directive or command syntax, a concise description, and a ready-to-use configuration or shell example.
Systemd replaced SysVinit and Upstart by providing a unified framework for managing services, mount points, devices, sockets, and timers through declarative unit files. Understanding systemd is essential for every Linux system administrator, DevOps engineer, and backend developer who deploys applications on Linux servers. This reference focuses on the directives and commands that engineers encounter daily: writing service unit files with proper dependency ordering, configuring restart policies, setting up timer-based cron replacements, and querying logs with journalctl.
Whether you are writing a .service unit file to run a Node.js application with automatic restart on failure, creating a .timer unit to schedule nightly database backups using OnCalendar syntax, enabling socket activation for on-demand service startup, filtering journalctl output by service, priority, and time range, or analyzing boot performance with systemd-analyze blame, this cheat sheet provides the exact syntax and parameters. All content runs in the browser with no server dependency.
Key Features
- Unit file [Unit] section directives including Description, After/Before ordering, Requires (hard dependency), Wants (soft dependency), and [Install] WantedBy for boot target linkage
- Service section covering Type=simple, Type=forking, and Type=oneshot, Restart policies (always, on-failure, no), RestartSec delay, ExecStartPre commands, Environment/EnvironmentFile, and User/Group execution context
- Timer unit configuration with OnBootSec for post-boot delays, OnCalendar for cron-style scheduling (daily, weekly, *-*-* HH:MM:SS), OnUnitActiveSec for repeat intervals, Persistent=true for missed execution compensation, and systemctl list-timers
- Socket activation with ListenStream for TCP, ListenDatagram for UDP, Accept=yes for per-connection service instances, and socket-to-service on-demand startup patterns
- journalctl queries including -u for service-specific logs, -f for real-time streaming, --since/--until for time-range filtering, -p for priority filtering (emerg through debug), and --disk-usage/--vacuum-size for journal maintenance
- systemctl operations: start/stop/restart, enable/disable for boot persistence, status for state and recent log inspection, daemon-reload after unit file edits, list-units filtering, mask/unmask for full disable, and cat for viewing unit file contents
- Target management with multi-user.target, graphical.target, rescue.target, and systemctl get-default/set-default for default boot target configuration
- Boot analysis tools: systemd-analyze for total boot time, blame for per-service timing, critical-chain for dependency chain visualization, and plot for SVG timeline generation
Frequently Asked Questions
What is the difference between Requires= and Wants= in a unit file?
Requires= creates a hard dependency: if the required unit fails to start, the dependent unit also fails. Wants= creates a soft dependency: the wanted unit is started in parallel, but if it fails, the dependent unit still starts normally. In practice, Wants= is preferred for most dependencies because it makes the system more resilient. Requires= is used when a service genuinely cannot function without another (e.g., a database-dependent app requiring postgresql.service).
How do I choose between Type=simple, Type=forking, and Type=oneshot?
Use Type=simple (the default) when the ExecStart process is the main service process and remains running. Use Type=forking when the process daemonizes by forking and the parent exits (common with traditional daemons, often requires PIDFile=). Use Type=oneshot for scripts or commands that run to completion and exit, where systemd should consider the service active until ExecStart finishes. Type=notify is also useful for services that signal readiness via sd_notify().
How do I replace a cron job with a systemd timer?
Create two files: a .service unit with the command to execute (Type=oneshot), and a matching .timer unit with the schedule. Use OnCalendar= for calendar-based scheduling: OnCalendar=daily, OnCalendar=Mon *-*-* 03:00:00, or OnCalendar=*-*-* *:00/15:00 for every 15 minutes. Add Persistent=true to catch up on missed runs. Enable with systemctl enable --now myservice.timer. Check scheduled timers with systemctl list-timers.
What does systemctl daemon-reload do and when is it needed?
systemctl daemon-reload tells systemd to re-read all unit files from disk. It is required after you create, modify, or delete any unit file in /etc/systemd/system/ or /usr/lib/systemd/system/. Without it, systemd continues using the cached version of the unit file. Always run daemon-reload before restarting a service after editing its unit file. It does not restart any services; it only reloads the configuration.
How do I view and filter logs with journalctl?
Use journalctl -u service-name to view logs for a specific service. Add -f for real-time streaming (like tail -f). Filter by time with --since "2024-01-01 00:00" --until "2024-01-02". Filter by priority with -p err (shows err and above: emerg, alert, crit, err). Combine filters: journalctl -u nginx -p warning --since today. Use -b to limit to the current boot, or -b -1 for the previous boot. Output as JSON with -o json-pretty.
What is socket activation and when should I use it?
Socket activation lets systemd listen on a socket (TCP port, Unix domain socket, etc.) and start the associated service only when a connection arrives. This reduces resource usage for infrequently accessed services and enables zero-downtime restarts. Create a .socket unit with ListenStream= and a matching .service unit. Systemd passes the open file descriptor to the service. Use Accept=yes if each connection should spawn a separate service instance.
How do I troubleshoot a service that fails to start?
Start with systemctl status service-name to see the active state, exit code, and last few log lines. Then use journalctl -u service-name -n 50 --no-pager for more detailed logs. Check the unit file with systemctl cat service-name. Common issues include wrong ExecStart paths, missing Environment variables, permission problems (check User/Group), and dependency ordering issues (After=/Requires= directives). Use systemd-analyze verify service-name to check unit file syntax.
What are systemd targets and how do they relate to runlevels?
Targets are grouping units that replace the old SysVinit runlevels. multi-user.target corresponds to runlevel 3 (console, multi-user, no GUI) and is the default for servers. graphical.target corresponds to runlevel 5 (desktop with GUI). rescue.target is single-user mode (runlevel 1). emergency.target provides a minimal shell. Use systemctl set-default to change the boot target. Services declare WantedBy= in their [Install] section to specify which target should start them.