From SysVinit to systemd: An Overview of Traditional Linux Init Systems

From SysVinit to systemd

In recent years Linux init processes have evolved significantly: the traditional SysVinit has faded, while Upstart and systemd have emerged with distinct features, and most modern distributions now adopt systemd. This first part of a series focuses on SysVinit’s characteristics and usage.

What is an Init system? History and current status

The Linux boot process starts with BIOS, then the bootloader loads the kernel, which finally starts the init process (PID 1). This init process is the ancestor of all other processes and is responsible for launching the rest of the system.

Init systems define, manage, and control the behavior of this first process, organizing the various initialization tasks required to bring the system into a usable state, such as starting a shell or a graphical interface.

Most Linux distributions historically used SysVinit, a System V‑compatible init. Some, like Slackware, used BSD‑style init, while others (e.g., Gentoo) have custom solutions. Ubuntu and RHEL moved to Upstart, and Fedora switched to systemd starting with version 15.

This series will cover the three major init systems—SysVinit, Upstart, and systemd—highlighting their design differences and basic usage.

SysVinit Overview

SysVinit, derived from UNIX System V, offers greater flexibility than BSD‑style init and has been the default for decades across many Linux distributions.

Runlevels

SysVinit uses “runlevels” to define preset operating modes. The /etc/inittab file may contain an initdefault entry that selects the default runlevel; otherwise the user is presented with a console to choose manually.

Typical runlevels are 0 (halt), 1 (single‑user mode), 2‑5 (multi‑user modes, with 5 usually providing a GUI), and 6 (reboot). Different distributions map these levels slightly differently, but 0, 1, and 6 are universally recognized.

SysVinit Startup Sequence

During boot SysVinit reads /etc/inittab to determine the target runlevel and then executes the following steps in order:

/etc/rc.d/rc.sysinit

/etc/rc.d/rc and the appropriate /etc/rc.d/rcX.d/ directory (where X is the runlevel)

/etc/rc.d/rc.local

X Display Manager (if a graphical interface is requested)

The rc.sysinit script performs essential tasks such as activating udev and SELinux, applying kernel parameters from /etc/sysctl.conf , setting the system clock, loading keymaps, enabling swap, configuring hostname, checking and remounting the root filesystem, activating RAID/LVM, enabling disk quotas, mounting all filesystems, and cleaning stale locks and PID files.

After rc.sysinit , SysVinit runs the /etc/rc.d/rc script, which invokes all scripts in the /etc/rc.d/rcX.d/ directory corresponding to the chosen runlevel. Scripts prefixed with S are start scripts; their numeric suffix determines execution order. These are symbolic links to real scripts located in /etc/init.d . An example listing of /etc/rc5.d/ is shown below:

[root@www ~]# ll /etc/rc5.d/
lrwxrwxrwx 1 root root 16 Sep  4  2008 K02dhcdbd -> ../init.d/dhcdbd
... (omitted) ...
lrwxrwxrwx 1 root root 14 Sep  4  2008 K91capi -> ../init.d/capi
lrwxrwxrwx 1 root root 23 Sep  4  2008 S00microcode_ctl -> ../init.d/microcode_ctl
lrwxrwxrwx 1 root root 22 Sep  4  2008 S02lvm2-monitor -> ../init.d/lvm2-monitor
... (omitted) ...
lrwxrwxrwx 1 root root 17 Sep  4  2008 S10network -> ../init.d/network
... (omitted) ...
lrwxrwxrwx 1 root root 11 Sep  4  2008 S99local -> ../rc.local
lrwxrwxrwx 1 root root 16 Sep  4  2008 S99smartd -> ../init.d/smartd
... (omitted) ...

When all start scripts finish, SysVinit executes /etc/rc.d/rc.local , a user‑customizable script for additional configuration.

SysVinit Shutdown

During shutdown, SysVinit runs scripts prefixed with K in the appropriate rcX.d directory, ensuring services that access the filesystem are stopped before the filesystems are unmounted, thus preserving data integrity.

Management and Control Tools

SysVinit provides a suite of command‑line utilities for process control and system management, including:

halt – stop the system

init – the init process itself (PID 1)

killall5 – send signals to all processes except those in the current session

last – display login history from /var/log/wtmp

lastb – show failed login attempts from /var/log/btmp

mesg – control write access to your terminal

pidof – find process IDs by name

poweroff – shut down and cut power

reboot – restart the system

runlevel – display current and previous runlevels

shutdown – safely terminate the system with notifications

sulogin – provide a login prompt in single‑user mode

telinit – send signals to the init process to change runlevels

utmpdump – display the contents of /var/run/utmp in a readable format

wall – broadcast a message to all logged‑in users

Distributions often extend these tools; for example, Red Hat’s RHEL adds the initscripts package with service and chkconfig commands and graphical interfaces for init management.

Summary of SysVinit

SysVinit’s strengths lie in its simplicity and deterministic execution order, making it easy for developers to write start/stop scripts and for administrators to troubleshoot. However, its serial execution can lead to slower boot times, prompting the development of newer init systems like Upstart and systemd that support parallel startup and faster boot performance.

Upstart was the first widely adopted next‑generation init system, and systemd is now the dominant choice across most modern Linux distributions.