Linux Init Systems: From SysV to systemd

The Heartbeat of Linux

At the very core of every Linux system beats a special process - PID 1, the init system. This is the first process started by the kernel and the last one to die when the system shuts down. It's the ancestor of all other processes, the supervisor of system services, and the orchestrator of your system's lifecycle.

Think of the init system as the conductor of an orchestra. While the kernel provides the instruments (hardware resources), the init system coordinates when each musician (service) plays, ensuring they work in harmony. Some conductors (SysV Init) follow a strict, sequential score, while others (systemd) allow sections to play simultaneously for a faster, more dynamic performance.

The evolution from SysV Init to systemd represents one of the most significant changes in Linux history, transforming how we think about system initialization and service management.

Interactive Init Systems Comparison

Explore the differences between major init systems and how they manage your Linux system:

The Init Process Hierarchy

PID 1: The Immortal Process

The kernel searches for init in order: /sbin/init, /etc/init, /bin/init, /bin/sh. If none found, kernel panics. PID 1 never exits - it's the ancestor of all processes and adopts orphans.

# View process tree
pstree -p
# systemd(1)───systemd-journal(289)
#           ├──systemd-udevd(315)
#           ├──sshd(890)───bash(1235)
#           └──nginx(1001)───nginx(1002)

SysV Init: The Traditional Approach

Sequential startup: Services start one at a time based on numeric order. Simple but slow.

Runlevels: System states controlling which services run.

• 0: Halt/Shutdown
• 1: Single user mode (rescue)
• 3: Multiuser with network
• 5: Multiuser with GUI
• 6: Reboot

# Change runlevel
init 3
telinit 5

# Check current
runlevel

Service Management

Scripts in /etc/init.d/ handle start, stop, restart. Simple shell scripts with case statements.

# Start/stop services
service httpd start
service httpd stop

# Enable/disable at boot
chkconfig httpd on
chkconfig --list

systemd: The Modern Powerhouse

Parallel startup: Services start simultaneously when dependencies met. Fast and efficient.

Unit files: Declarative configuration (not shell scripts).

# /etc/systemd/system/myapp.service
[Unit]
Description=My Application
After=network.target
Requires=postgresql.service

[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

Unit Types

• .service: System services (nginx, postgresql)
• .socket: Network sockets for activation
• .target: Groups of units (like runlevels)
• .timer: Scheduled tasks (replaces cron)
• .mount: Filesystem mount points
• .path: Path-based activation

systemd Commands

# Service management
systemctl start nginx
systemctl status nginx
systemctl enable nginx

# System state
systemctl list-units --failed
systemctl get-default

# Logs
journalctl -u nginx
journalctl -f
journalctl -b

# Analyze boot
systemd-analyze
systemd-analyze blame

Advanced Features

Timer Units: Replace cron with OnCalendar=daily scheduling.

Socket Activation: Services start on-demand when socket receives connection. Faster boot.

OpenRC: The Elegant Alternative

Dependency-based: Services declare dependencies explicitly (need, use, after, before). Parallel startup within constraints.

# Service control
rc-service nginx start
rc-status

# Enable at boot
rc-update add nginx default

# Runlevels: boot, default, nonetwork, shutdown

Comparison: SysV vs systemd vs OpenRC

Process Supervision

systemd monitors services and can automatically restart on failure:

• Restart=on-failure: Restart if exits with error
• Restart=always: Always restart
• RestartSec=5s: Delay between restarts
• Watchdog: Application pings systemd to prove it's alive

Advanced systemd Features

Generators: Create units dynamically at boot (e.g., mount units from /etc/fstab).

Drop-in Directories: Override unit settings without modifying originals.

systemctl edit nginx  # Creates override in /etc/systemd/system/nginx.service.d/

Template Units: Instantiate multiple services from one template.

# app@.service → app@web.service, app@api.service
systemctl start app@web.service

Migration: SysV to systemd

Convert SysV scripts to systemd units: replace shell case statements with declarative [Service] sections. Set Type=forking for daemons.

Troubleshooting

# Service fails
systemctl status failed-service
journalctl -u failed-service

# Dependency issues
systemctl list-dependencies service

# Emergency mode
systemctl rescue

Best Practices

1. Set proper dependencies (After/Requires)
2. Handle SIGTERM for graceful shutdown
3. Use restart policies for critical services
4. Test with systemd-analyze verify

See Boot Process for complete system startup visualization.

Related Concepts

• Boot Process: Complete BIOS→kernel→init journey
• Process Management: How processes work
• Kernel Architecture: System architecture overview