The Evolution of Init: The Comprehensive Systemd
- The Evolution of Init and Full-Featured Systemd
1.1 Three Major Versions of Init in Linux Systems
The first user-space process started by the kernel is init. Linux systems have primarily used three versions of init:
- System V init (SysV traditional sequential startup, now outdated) - configuration in /etc/inittab
- Upstart (used by Ubuntu) - configuration in /etc/init with .conf files
- systemd (parallel on-demand startup, current mainstream) - configuration in /usr/lib/systemd/ and /etc/systemd/
Following Linux conventions, the letter 'd' stands for daemon. Systemd's name reflects its purpose: to守护 the entire system. Systemd serves as the system and service manager for Linux. It's compatible with SysV and LSB init scripts and can replace sysvinit. Systemd handles everything from system initialization and service management to system hibernation, sleep, and shutdown. Some describe it as an operating system in itself, and it has become the standard for most distributions.
1.2 Systemd Features Compared to Traditional Init Programs
- Faster startup speed: Utilizes technologies like socket and D-Bus activation for service startup
- On-demand daemon activation: Services start only when needed
- Process lifecycle management: Employs Linux Cgroup features to track and manage processes, ensuring clean service shutdown and resource回收
- Mount point management: Includes built-in automount services that provide autofs functionality without requiring separate installation
- Transactional dependency management: Ensures proper service startup sequences
- System snapshots and restoration: (Note: This feature was not fully developed in 2014)
- Integrated logging service: Includes journald, wich addresses limitations of traditional syslog services
1.3 Advantages of Systemd Journal
- Simplicity: Minimal code, fewer dependencies, and reduced abstraction overhead
- Zero maintenance: As logging is core to debugging and monitoring, the service itself is designed not to create problems. For example, it automatically manages disk space to prevent exhaustion from continuous log generation
- Portability: Log files remain accessible across all Linux system types regardless of CPU architecture or byte order
- Performance: Fast log addition and browsing
- Minimal resource usage: Log data files are compact
- Unification: Consolidates various logging technologies into a single data store, preserving global context for future queries. Unlike syslog which saves information to separate files, systemd maintains relationships between related entries (firmware, kernel, and user-space records)
- Scalability: Suitable for environments ranging from embedded devices to supercomputer clusters
- Security: Log files are verifiable, preventing undetectable modifications
- Core Concepts of Systemd
2.1 Unit Concept (12 Types)
Each step in the boot process is abstracted by systemd as a configuration unit, or unit. A service can be considered a unit; a mount point is a unit; a swap partition configuration is a unit, and so on. Systemd categorizes units into the following 12 types:
- Service unit: System services representing background processes (e.g., mysqld)
- Socket unit: IPC sockets encapsulating system and internet sockets. Each socket unit has a corresponding service unit that activates when a connection is established
- Device unit: Hardware devices present in the Linux device tree, identified through udev rules
- Mount unit: Filesystem mount points managed and monitored by systemd
- Automount unit: Automatic mount points that trigger mounting when accessed
- Swap unit: Swap files managed similarly to mount units
- Timer unit: Timers for triggering user-defined operations, replacing traditional atd and crond services
- Target unit: Groups of multiple units that don't perform actions themselves but reference other units, providing unified control similar to runlevels
- Snapshot unit: Systemd snapshots that allow returning to previous states
- Path unit: Files or paths that trigger actions
- Scope unit: External processes not started by systemd, typically managed through systemd bus interfaces
- Slice unit: Process groups that manage resources through Linux control groups (cgroups)
2.1.1 Viewing Units
# List currently running units
$ systemctl list-units
# List all units, including those without configuration files or that failed to start
$ systemctl list-units --all
The list fields include: UNIT, LOAD, ACTIVE, SUB, DESCRIPTION
- LOAD: Indicates whether the unit definition was properly loaded (loaded, not-found)
- ACTIVE: High-level activation status (active, failed, inactive)
- SUB: Low-level activation status specific to the unit type (active, dead, exited, failed, listening, mounted, plugged, running, waiting)
# List all inactive units
$ systemctl list-units --all --state=inactive
# List all failed units
$ systemctl list-units --failed
# List all running service units
$ systemctl list-units --type=service
2.1.2 Unit Status
# Display system status
$ systemctl status
# Display status of a specific unit
$ systemctl bluetooth.service status
# Check if a unit is currently running (useful for scripting)
$ systemctl is-active application.service
# Check if a unit has failed to start
$ systemctl is-failed application.service
# Check if a unit has startup links enabled
$ systemctl is-enabled application.service
2.1.3 Unit Management Operations
# Immediately start a service
$ sudo systemctl start apache.service
# Immediately stop a service
$ sudo systemctl stop apache.service
# Restart a service
$ sudo systemctl restart apache.service
# Kill all processes of a service
$ sudo systemctl kill apache.service
# Reload a service's configuration
$ sudo systemctl reload apache.service
# Reload all modified configuration files
$ sudo systemctl daemon-reload
# Display all parameters of a unit
$ systemctl show httpd.service
# Display a specific property of a unit
$ systemctl show -p CPUShares httpd.service
# Set a specific property of a unit
$ sudo systemctl set-property httpd.service CPUShares=500
2.1.4 Unit Dependencies
Systemd units can define dependencies between each other. For example, if unit A depends on unit B, this can be expressed as "require A" in unit B's definition, ensuring systemd starts A before B.
# List all dependencies of a unit
$ systemctl list-dependencies nginx.service
# Expand target dependencies (by default, targets are not expanded)
$ systemctl list-dependencies --all nginx.service
2.2 Unit Configuration Files
Each unit has a corresponding configuration file that tells Systemd how to start it. Systemd reads configuration files from /etc/systemd/system/ by default, but most files there are symbolic links to /usr/lib/systemd/system/, where the actual configurations reside.
2.2.1 Configuration File Status
# List all configuration files
$ systemctl list-unit-files
2.2.2 Counting Configuration Files
Configuration files can be in various states:
- disabled: No startup links established; won't start on boot
- enabled: Startup links established; will start on boot
- enabled-runtime: Enibled during runtime
- generated: Dynamically generated
- indirect: Indirectly enabled
- static: No [Install] section; can only be a dependency for other units
- transient: Temporary configuration
- masked: Prohibited from establishing startup links
Configuration files can have various extensions (unit types):
- automount, mount, path, scope, service, slice, socket, swap, target, timer, device, snapshot
2.2.3 Viewing Configuration Files
# List configuration files of a specific type
$ systemctl list-unit-files --type=service
# After modifying configuration files, reload systemd and restart services
$ sudo systemctl daemon-reload
$ sudo systemctl restart httpd.service
Configuration file format consists of three sections, with section and field names being case-sensitive. For detailed information on writing unit files, refer to official documentation.
2.3 Targets
When booting a computer, numerous units need to be started. Systemd solves this with Targets, which are groups of related units. This is similar to the traditional RunLevel concept, but with a key difference: RunLevels are mutually exclusive, while multiple Targets can be active simultaneously.
2.3.1 Target Commands
# List all system targets
$ systemctl list-unit-files --type=target
# List all units in a target
$ systemctl list-dependencies multi-user.target
# View the default target at boot
$ systemctl get-default
# Set the default target at boot
$ sudo systemctl set-default multi-user.target
# Switch targets, closing processes not in the new target
$ sudo systemctl isolate multi-user.target
2.3.2 Target Correspondence with Traditional RunLevels
| Traditional Runlevel | New Target Name | Description |
|---|---|---|
| Runlevel 0 | runlevel0.target → poweroff.target | Shut down the system |
| Runlevel 1 | runlevel1.target → rescue.target | Single-user mode |
| Runlevel 2 | runlevel2.target → multi-user.target | User-defined/domain-specific runlevel (default same as 3) |
| Runlevel 3 | runlevel3.target → multi-user.target | Multi-user, non-graphical |
| Runlevel 5 | runlevel5.target → graphical.target | Multi-user, graphical |
| Runlevel 6 | runlevel6.target → reboot.target | Reboot |
| Emergency | emergency.target | Emergency shell |
2.4 Systemd Transactions
Systemd ensures transactional integrity by preventing circular references between dependent units. If circular dependencies exist, systemd attempts to resolve them by converting required dependencies to wants dependencies where possible. If resolution fails, systemd reports an error, automatically detecting and fixing configuration issues.
2.5 Systemd Concurrent Startup Principles
Systemd resolves dependencies through three main approaches:
- Socket dependency resolution: Services activated via sockets can start independently of their dependencies
- D-Bus dependency resolution: D-Bus (desktop-bus) provides low-latency, low-overhead IPC increasingly used for application communication and with the kernel
- Filesystem dependency resolution: Techniques for handling dependencies on mounted filesystems
2.6 Using Systemd for Development
For developers creating new system services, consider these key points for systemd integration:
- Background service processes don't need to double-fork; implement only the main loop
- Don't call setsid() - let systemd handle it
- No need to maintain PID files
- Output to stderr instead of using syslog (systemd provides logging)
- Handle SIGTERM for service termination and SIGHUP for restart
- For socket-based services, let systemd create the socket
- Use sd_notify() to notify systemd of state changes, especially when initialization is complete
2.7 System Management
Systemd provides a comprehensive suite of commands for system management, with systemctl being the primary tool.
2.7.1 System Shutdown, Restart, and Sleep
# Restart the system
$ sudo systemctl reboot
# Shut down and power off
$ sudo systemctl poweroff
# Stop CPU operations
$ sudo systemctl halt
# Suspend the system (devices powered on, data in memory)
$ sudo systemctl suspend
# Hibernate the system (devices powered off, memory saved to disk)
$ sudo systemctl hibernate
# Hybrid sleep (data in both memory and disk)
$ sudo systemctl hybrid-sleep
# Enter rescue mode (single-user state)
$ sudo systemctl rescue
2.7.2 systemd-analyze for Startup Performance
# View total startup time
$ systemd-analyze
# View startup time for each service
$ systemd-analyze blame
# Display waterfall-style startup process
$ systemd-analyze critical-chain
# Display startup process for a specific service
$ systemd-analyze critical-chain atd.service
2.7.3 hostnamectl for Host Information
# Display current host information
$ hostnamectl
# Set hostname
$ sudo hostnamectl set-hostname newhostname
2.7.4 localectl for Locale Settings
# View locale settings
$ localectl
# Set locale parameters
$ sudo localectl set-locale LANG=en_GB.utf8
$ sudo localectl set-keymap en_GB
2.7.5 timedatectl for Timezone Settings
# View current timezone settings
$ timedatectl
# List all available timezones
$ timedatectl list-timezones
# Set current timezone
$ sudo timedatectl set-timezone America/New_York
$ sudo timedatectl set-time YYYY-MM-DD
$ sudo timedatectl set-time HH:MM:SS
2.7.6 loginctl for User Sessions
# List current sessions
$ loginctl list-sessions
# List currently logged-in users
$ loginctl list-users
# Display information for a specific user
$ loginctl show-username username
2.7.7 Additional Viewing Commands
View Status with Tree Listing
$ systemctl status
CGroup: /
├─user.slice
│ └─user-1001.slice
│ ├─session-2.scope
│ ├─ 507 lightdm --session-child 14 21
│ └─ 518 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
Unit List Display
$ systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File Format File System Automount Point
sys-devices-pci0000:00-0000:00:02.0-backlight-acpi_video0.device loaded active ACPI Video Device
sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2dLVDS\x2d1-intel_backlight.device loaded active Intel® Graphics Card
List Dependencies
$ systemctl list-dependencies
default.target
● ├─lightdm.service
● └─multi-user.target
● ├─dbus.service
● └─lm_sensors.service
Tree Process Display
$ ps xawf -eo pid,user,cgroup,args
PID USER CGROUP COMMAND
2 root - [kthreadd]
3 root - \_ [rcu_gp]
4 root - \_ [rcu_par_gp]
6 root - \_ [kworker/0:0H-kblockd]
Tree Display
$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1001.slice
│ ├─session-2.scope
│ │ ├─ 507 lightdm --session-child 14 21
│ │ └─ 518 /bin/sh /etc/xdg/xfce4/xinitrc -- /etc/X11/xinit/xserverrc
Service Types
When writing custom service files, different startup types should be considered using the Type= paramter in the [Service] section:
- Type=simple (default): The service starts immediately. The process must not fork. Don't use if other services need to be ordered on this service unless it's socket activated.
- Type=forking: The service starts once the process forks and the parent exits. For classic daemons, use this type and specify PIDFile=.
- Type=oneshot: Useful for scripts that perform a single job and exit. Set RemainAfterExit=yes to keep the service considered active after exit.
- Type=notify: Similar to simple, but the daemon notifies systemd when ready using libsystemd-daemon.so.
- Type=dbus: The service is ready when the specified BusName appears on DBus's system bus.
- Type=idle: Delays execution until all jobs are dispatched, otherwise similar to simple.
Creating Systemd Visualizations
To create systemd visualizations:
# Install graphviz
$ sudo pacman -S graphviz
# Create a system diagram
$ systemd-analyze dot --order | dot -Tsvg > systemd-system.svg
# Create a user session diagram
$ systemd-analyze dot --user --order | dot -Tsvg > systemd-user.svg
Troubleshooting Systemd
When investigating systemd issues:
- Diagnose boot problems with systemd-analyze
- Investigate service failures with systemctl status service-name
- Check logs with journalctl -xe for detailed error information
- Verify unit file syntax with systemd-analyze verify unit-file