Choosing an init system in Linux: detailed comparison of SysV, systemd, and alternatives

Introduction / Why This Matters

Choosing an init system is a fundamental decision when selecting or building a Linux distribution. The init system (PID 1) is the first process launched by the kernel, responsible for initializing the entire system, starting and controlling services (daemons), and handling shutdown.

Understanding the differences between systemd, SysV init, OpenRC, and runit is critical for:

• System Administrators: To effectively manage services and diagnose issues.
• Embedded Systems Developers: To minimize resource consumption.
• Enthusiasts: To create custom, lightweight, or specialized builds.
• Anyone encountering boot or service management problems.

This guide provides clear criteria for your choice, based not on ideology but on the practical needs of your project.

Requirements / Preparation

To follow this guide and make a meaningful comparison, you will need:

1. A basic understanding of Linux architecture (processes, daemons, kernel).
2. Access to a Linux terminal (a virtual machine is fine).
3. (Optional) The ability to boot Live-ISOs of various distributions for testing.

Architecture and Concept Comparison

What is PID 1?

It is the first process started by the kernel. Everything else is its child. Its job is to start the rest of the system and then must not "die" to avoid "zombie" processes. Modern init systems do much more.

Key Differences at a Glance

Detailed Breakdown of Each System

1. systemd: The Modern Standard

Architecture: Monolithic but modular. PID 1 (systemd) is the system and service manager. It manages:

• cgroups for isolation and resource accounting.
• Journal for centralized logging.
• D-Bus for IPC.
• Networking (networkd), login (logind), timers (timer units).

Advantages:

• Boot Speed: Parallel service startup based on dependencies.
• Power: Deep control over service lifecycle (restart, timeouts, resources).
• Integration: Single entry point (systemctl), unified log (journalctl).
• Standardization: De facto industry standard, vast support.

Disadvantages:

• Complexity: Large codebase, lots of "magic" under the hood.
• Resource Usage: Higher than alternatives (though still minimal).
• Philosophical Debates: Violates Unix philosophy of "one program, one task".

When to Choose: For desktops, servers, where speed, modern features (snapshots, isolation), and access to extensive documentation/community matter.

2. SysV init: The Classic

Architecture: Simple. PID 1 is init, which reads /etc/inittab and runs scripts from /etc/init.d/ according to the current runlevel (0-6). Managed via service and chkconfig.

Advantages:

• Simplicity: Small code, easy to read and debug.
• Stability: Proven over decades.
• Minimalism: Near-zero overhead.

Disadvantages:

• Slow Boot: Sequential service startup.
• Weak Management: No built-in dependency control, hard to manage dynamic services.
• Obsolescence: Most modern distributions have abandoned it.

When to Choose: Only for legacy systems, educational purposes, or in distributions that consciously rejected systemd (Devuan). Not for new projects.

3. OpenRC: Flexible and Compatible

Architecture: PID 1 is init, while service management is handled via scripts in /etc/init.d/ (SysV-compatible) and dependency files in /etc/conf.d/. Startup is parallel, but dependencies must be explicitly declared in scripts.

Advantages:

• Flexibility: SysV script compatibility with modern parallelism.
• Control: Understandable Bash/POSIX sh scripts.
• Minimalism: No global daemon, just init and rc.
• Reliability: Used in Alpine Linux (containers, routers) and Gentoo.

Disadvantages:

• Less "Out-of-the-Box": No built-in logging, network management, or session handling.
• Requires Manual Setup: Dependencies must be defined in each script.

When to Choose: For embedded systems, routers, container base images (Alpine), where you need a balance of simplicity and modern features. Ideal for Gentoo.

4. runit: Simplicity and Reliability

Architecture: PID 1 is runsvdir, which monitors directories in /etc/service/ (or /var/service/). For each service, it starts a runsv process that supervises a single process. Managed via sv (start/stop/status). Dependencies are implemented via wrapper scripts.

Advantages:

• Extreme Simplicity: Configuration is just a directory with an executable run file.
• Reliability: Automatic restart of crashed services.
• Minimalism: Very small size and memory footprint.
• Readability: Easy to understand how each service works.

Disadvantages:

• Very Little Built-In: Nothing beyond process management. Logging, timers—only via external tools.
• No Built-in Dependencies: Requires hacky solutions for complex chains.
• Less Common: Less documentation and examples than systemd/OpenRC.

When to Choose: For simple, isolated services (microservices), embedded systems where predictability and simplicity are key. Powers Void Linux.

Step-by-Step Guide: How to Choose?

Step 1: Identify Your Current Init System

ps -p 1 -o comm=

• systemd → you have systemd.
• init → likely SysV or OpenRC (check /etc/inittab or /etc/rc.conf).
• runit → you have runit.

Step 2: Answer Key Questions

1. What is the system for? (Desktop, server, embedded device, container).
2. Is maximum boot speed critical? (systemd > OpenRC ≈ runit > SysV).
3. Do you need complex dependencies between services? (systemd > OpenRC > runit > SysV).
4. Is memory/CPU consumption critical? (runit ≈ OpenRC < systemd).
5. Do you need built-in logging? (only systemd).
6. Do you plan to deeply customize? (OpenRC and runit are easier to understand and modify).

Step 3: Match Answers to the Table Above

• Desktop/modern server: systemd.
• Container/router (Alpine): OpenRC.
• Minimalist server/custom build (Void/Gentoo): runit or OpenRC.
• Legacy or maximum minimalism: SysV (only if no other choice).

Step 4: Test

Download Live-ISOs:

• Alpine Linux (OpenRC) — to test a lightweight system.
• Void Linux (runit) — to test a simple and fast system.
• Ubuntu/Fedora (systemd) — to test the standard. Boot them in a VM and try the management commands (rc-service, sv, systemctl).

Step 5: Decide

Choose a distribution that uses your desired init by default. Don't try to "force" a different init into Ubuntu or Fedora—that's a path to endless problems. If you need full control, use Gentoo or build from scratch (LFS).

Success Check

You have successfully chosen an init system if:

1. You understand its core concepts and philosophy.
2. You can clearly explain its advantages for your use case.
3. You can perform basic operations: start/stop/status of a service, enable/disable autostart.
4. You know where service configuration files are stored.
5. You consciously chose a distribution aligned with your choice.

Common Issues

Issue: "I need systemd but want minimalism"

Solution: Use distributions based on a minimal systemd without extra components (e.g., Debian netinst with only standard system utilities selected). Or configure systemd to disable unnecessary units (systemctl mask). Alternative: Alpine with OpenRC if systemd features aren't critical.

Issue: "OpenRC/runit can't handle complex dependencies like systemd"

Solution: For complex services (web server + DB + cache) in OpenRC/runit, you'll need to create "meta" wrapper scripts that start multiple services in order, or use external supervisors (supervisor, s6). In systemd, this is done declaratively in one file.

Issue: "I need journald but I'm on Alpine (OpenRC)"

Solution: Install and configure the classic logging stack: syslog-ng or rsyslog for log collection, and logrotate for rotation. For centralized collection, use fluentd or loki. There's no full journalctl replacement, but functionality is achievable.

Issue: "OpenRC service scripts won't start"

Solution: Check:

1. Script permissions in /etc/init.d/: must be executable (chmod +x).
2. Script syntax (must start with #!/sbin/openrc-run or be SysV-compatible).
3. Dependency file in /etc/conf.d/ (if used).
4. Output of: rc-service <service_name> start — it will show the error.

Issue: "runit service doesn't restart after crashing"

Solution: Ensure the service directory in /etc/service/ contains an executable run file and that it launches the process in the foreground (not as a daemon). runsv only manages foreground processes. Example run file:

#!/bin/sh
exec /usr/bin/myapp --config /etc/myapp.conf

(No & or nohup).