What is init system?

Overview and Purpose

An init system is a critical component of Unix-like and Linux operating systems that serves as the parent process for all other processes on the system. When the kernel finishes its initialization during boot, it executes the init system, which then takes responsibility for starting all other system services, daemons, and user processes. The init system manages the entire lifecycle of these processes and ensures proper system state transitions from boot through shutdown.

The init system is essential because it provides a structured approach to system initialization, service management, and graceful shutdown. Without an init system, the kernel alone would be insufficient to bring a system to a usable state or manage the complex interdependencies between services.

Historical Evolution

Init systems have evolved significantly over decades:

• SysVinit: The traditional init system used in System V Unix and early Linux distributions. It relies on runlevels (0-6) and shell scripts in /etc/init.d/ to manage services. Each runlevel represents a different system state (single-user, multi-user, graphical, shutdown, etc.).
• BSD init: A simpler approach used in BSD systems, relying on /etc/rc.conf configuration and sequential execution of shell scripts.
• Upstart: Developed by Canonical, introduced event-driven initialization as an alternative to SysVinit's runlevel model. It provided faster boot times and better service dependency management.
• systemd: The modern init system adopted by most major Linux distributions. It uses unit files, parallel service startup, and a comprehensive service management framework.

How Init Systems Work

Boot Process Integration

When a Linux system boots, the kernel performs hardware detection and core initialization, then transfers control to the init system. The init system then:

1. Reads configuration files that define the desired system state
2. Starts essential services and daemons according to configuration
3. Manages service dependencies to ensure correct startup order
4. Handles inter-process communication and coordination
5. Maintains the running system in the desired state
6. Manages graceful shutdown when requested

Process Management

Init systems handle several critical process management tasks:

• Spawning services: Starting background daemons and services defined in configuration
• Dependency resolution: Ensuring services start in the correct order based on their dependencies
• Respawning: Automatically restarting failed services to maintain system stability
• Process grouping: Organizing related processes into logical units for coordinated control
• Signal handling: Receiving signals like SIGTERM and SIGKILL for graceful shutdown

Key Components and Concepts

Configuration Methods

Different init systems use different configuration approaches:

• SysVinit runlevels: Discrete system states (runlevel 2 for multi-user, 5 for graphical, etc.) with associated startup scripts
• Upstart jobs: Event-based configuration files defining service startup conditions and interdependencies
• systemd units: Modular configuration files (.service, .socket, .timer, .mount) in standardized INI format

Service Dependencies

Init systems manage complex service dependencies. For example, a web server might depend on networking being initialized, the filesystem being mounted, and a database service being running. The init system resolves these dependencies and ensures correct startup sequence.

Runlevels and Target States (systemd)

Traditional SysVinit uses runlevels to represent different system states. Modern systemd replaces this with targets that represent desired system states (multi-user.target, graphical.target, rescue.target, etc.).

systemd: The Modern Standard

systemd has become the dominant init system in contemporary Linux distributions due to its features:

• Parallel startup: Services start concurrently rather than sequentially, dramatically reducing boot time
• Unit-based configuration: Flexible, modular configuration using standardized unit files
• Socket activation: Services can be started on-demand when their network sockets receive connections
• Timer units: Built-in scheduling similar to cron without requiring a separate daemon
• Journal logging: Centralized, indexed logging through systemd-journald
• Resource control: Cgroup integration for limiting CPU, memory, and I/O resources
• User services: Support for per-user service instances
• Dependency tracking: Sophisticated dependency management with before/after relationships

Common Use Cases

Service Management

Administrators use init systems to manage critical services. For example, starting a web server at boot, ensuring it restarts if it crashes, and stopping it cleanly during shutdown.

System States

Init systems manage transitions between different system states, such as transitioning from single-user maintenance mode to full multi-user operation, or initiating graceful shutdown sequences.

Dependency Coordination

Complex systems with multiple interdependent services rely on the init system to orchestrate startup in the correct order. A database server must start before applications that depend on it.

Best Practices

• Understand your init system: Know whether your systems use SysVinit, Upstart, or systemd and learn its specific commands and configuration format
• Create proper unit files: Write clear, maintainable service definitions with explicit dependencies rather than relying on startup order
• Use dependency declarations: Explicitly declare service dependencies (Before, After, Requires, Wants) rather than assuming startup order
• Enable services correctly: Use systemctl enable or equivalent to ensure services start at boot, not just start them manually
• Monitor service status: Regularly check service status and logs to ensure expected services are running
• Plan graceful shutdown: Ensure services can be stopped cleanly and handle shutdown signals properly
• Document dependencies: Maintain clear documentation of service interdependencies for troubleshooting and maintenance

Practical Examples

systemd Service File Example

[Unit]
Description=My Web Application
After=network.target database.service
Requires=database.service

[Service]
Type=simple
User=appuser
ExecStart=/usr/local/bin/myapp
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

This systemd service file defines a web application that requires the database service to be running first, runs as a specific user, and automatically restarts if it fails.

SysVinit Runlevel Example

In SysVinit, runlevel 3 represents multi-user text mode, runlevel 5 represents graphical mode. Transitioning between them involves stopping and starting different sets of services defined in /etc/init.d/ scripts.

Troubleshooting Considerations

• Service won't start: Check dependencies and ensure prerequisite services are available
• Circular dependencies: Identify and resolve circular service dependencies that prevent startup
• Boot hangs: Services that don't signal completion can delay boot; verify proper Type declarations
• Failed restarts: Review logs to understand why services fail and set appropriate restart policies