Linux concept: SysV init

1. The Basics

SysV init (say it "System Five init") is the traditional init system for Unix and Linux: the software that the kernel starts first and that then brings the rest of the machine to life. Like every init system, its core program runs as process ID 1 (PID 1) and stays alive until shutdown. What makes it "SysV" is how it decides what to start: a fixed set of numbered system states called runlevels, and a directory of shell scripts that it runs in order to enter or leave each state.

There are three moving parts, and once you see them the whole system makes sense:

• The program /sbin/init, running as PID 1, the parent of every other process.
• A single configuration file, /etc/inittab, that tells init which runlevel to boot into and what to do in each one.
• A directory of start/stop scripts, /etc/init.d, one script per service, plus a set of rcN.d directories full of symbolic links that decide the order.

That is the entire mental model. init is a simple dispatcher; the real work of starting a service lives in an ordinary shell script that understands the words start and stop. This simplicity was SysV init's great strength (anyone who could write a shell script could add a service) and, as we will see, its great weakness (init itself understood almost nothing about the services it launched).

The right mental model: SysV init is a dispatcher that walks through numbered runlevels and runs hand-written shell scripts to start and stop services. It launches programs, but unlike systemd it does not truly supervise them.

1.1 What Makes PID 1 Special

Being process 1 is not just a small number; it comes with duties the kernel gives to no other process. Every init system, SysV init included, has to carry them, because it is the one process the whole system is built around:

• It is the ancestor of everything. When any process's parent dies, that process becomes an orphan, and the kernel hands it to PID 1 to look after. So init ends up as the adoptive parent of every stray process on the machine.
• It must reap zombies. When a process exits, it stays in the process table as a zombie until its parent collects the exit status with wait(). For the orphans it adopts, that parent is init. If init failed to reap them, the process table would slowly fill with dead entries, so reaping is a permanent background job of PID 1.
• It cannot simply exit. PID 1 has to stay alive for the whole life of the system. If it dies, there is no process left to manage user space, and the kernel panics.
• It gets special signal treatment. The kernel does not apply default signal actions to PID 1, so a stray signal cannot accidentally kill the one process the system depends on.

This is worth knowing because it is the part of init that has never changed. SysV init, Upstart, and systemd all handle runlevels, units, and services very differently, but every one of them must adopt orphans, reap zombies, and never exit. It is the irreducible core of being PID 1.

1.2 Where SysV init Still Lives Today

On a modern systemd machine, /sbin/init is no longer the old init program. It is a symbolic link to systemd, which keeps the old name and boot loaders working:

$ ls -l /sbin/init
/sbin/init → /lib/systemd/systemd

Yet the SysV layout is still all around you, because systemd deliberately stays compatible with it. The directories and commands below are the SysV world; on a systemd system they are a compatibility layer, but on a true SysV system they are the system:

$ ls -d /etc/rc*.d
/etc/rc0.d  /etc/rc1.d  /etc/rc2.d  /etc/rc3.d
/etc/rc4.d  /etc/rc5.d  /etc/rc6.d  /etc/rcS.d

$ ls /etc/init.d | head -4
anacron
bluetooth
cron
mysql

1.3 The Runlevels at a Glance

A runlevel is a numbered system state that says which group of services should be running. Init can be in exactly one runlevel at a time, and you switch states by telling it to change. The numbers are a long-standing convention:

Two of these are not really "states" you sit in: entering runlevel 0 halts the machine and entering 6 reboots it. That is why you never set your default runlevel to 0 or 6: the system would shut down or reboot forever. The meanings of 2 to 5 are only conventions and differ between distributions, a point we return to in section 7.

3. A Short History

init is one of the oldest ideas in Unix, older than Linux itself. Some form of an "init" process has existed since the earliest Unix in the 1970s, because a system always needs one first process to start the rest.

The specific design we call SysV init came from AT&T UNIX System V in 1983, which formalised the idea of numbered runlevels and a central /etc/inittab file. This was the model Linux adopted. The most widely used Linux implementation, the sysvinit package, was written by Miquel van Smoorenburg in the early 1990s and became the default init on nearly every Linux distribution for the next two decades.

For a long time it simply worked, and no one thought much about it. But as machines gained many cores and many services, its weaknesses began to hurt: it started services strictly one after another, so boot was slow; each service was a fragile hand-written script; and init could not really track a service once it had started. Two replacements set out to fix this:

• Upstart, shipped by Ubuntu in 2006, reacted to events rather than following a fixed script order, but kept the script-heavy style.
• systemd, released in 2010, replaced init entirely with declarative unit files, parallel startup, and reliable process tracking through control groups.

SysV init is not quite dead. A handful of distributions keep it on purpose, container base images sometimes use a tiny init, and every mainstream distribution still ships the service command and the /etc/init.d directory so that old scripts keep working. Learning it is less about running it in production and more about reading the many systems and scripts that still assume it.

These are the distributions to reach for if you want to run without systemd on purpose. Note that Slackware is technically BSD-style rather than strictly SysV, but in daily use it feels the same: plain shell scripts starting services in a fixed order.

systemd is also not the only alternative. Beside classic SysV init sit a family of lighter init systems that keep the small-and-simple spirit while adding proper service supervision: OpenRC (the default on Gentoo and Alpine, which still uses /etc/init.d scripts), and the minimalist runit, s6, and dinit. They matter mostly on lightweight or systemd-free systems, but they show that the choice was never simply "SysV or systemd".

5. Moderate Use Cases

To go beyond running services, you need to understand the two files that drive SysV init: the /etc/inittab configuration and the rcN.d symlink directories.

5.1 Reading /etc/inittab

On a true SysV system, /etc/inittab is the master switchboard. Every line has four colon-separated fields:

id:runlevels:action:process

A typical inittab looks like this:

id:5:initdefault:                      # boot into runlevel 5 by default
si::sysinit:/etc/init.d/rcS            # one-time early setup
l3:3:wait:/etc/init.d/rc 3            # entering runlevel 3: run the rc script for 3
l5:5:wait:/etc/init.d/rc 5            # entering runlevel 5: run the rc script for 5
ca::ctrlaltdel:/sbin/shutdown -r now  # what Ctrl-Alt-Del does
1:2345:respawn:/sbin/getty 38400 tty1 # a login prompt on tty1, restarted if it dies

Two lines carry most of the meaning. The initdefault line sets the runlevel the machine boots into; changing its number changes the default boot state. The respawn lines are the one place init really does supervise something: if a getty (the login prompt) exits, init starts it again, which is why a fresh login prompt appears the moment you log out of a text console.

5.2 The rcN.d Directories: S and K Links

When init enters a runlevel, it runs one script, /etc/init.d/rc N, which looks in the matching /etc/rcN.d directory. That directory is full of symbolic links back to the real scripts in /etc/init.d, and the link names encode the order and the action:

$ ls -l /etc/rc2.d
K01speech-dispatcher → ../init.d/speech-dispatcher
S01cron              → ../init.d/cron
S01mysql             → ../init.d/mysql
S01docker            → ../init.d/docker

The naming rule is simple and is the heart of SysV init:

• A link starting with S means Start: run the script with start when entering this runlevel.
• A link starting with K means Kill: run the script with stop when entering this runlevel.
• The two digits after the letter set the order. Scripts run in numeric order, so S10 runs before S20. This lets you start a database before the web server that needs it.

Classic systems spread the numbers out (S20apache2, K80apache2) to hand-tune the order. Newer Debian and Ubuntu compute the order from dependencies and give almost everything S01, which is why the example above shows so many S01 links.

5.3 Enabling a Service the SysV Way

You rarely make those symlinks by hand. Each distribution family has a tool that creates and removes them for you, reading the dependency headers inside the init script:

# Debian and Ubuntu
$ sudo update-rc.d cron defaults   # create S/K links in the default runlevels
$ sudo update-rc.d cron remove     # remove all its links

# Red Hat and SUSE
$ sudo chkconfig cron on           # enable at boot
$ sudo chkconfig --list cron       # show its runlevels

This is the SysV equivalent of systemctl enable. In both worlds, "enabling" a service means recording, in a fixed place, that it should start at boot. Here that record is a symlink; under systemd it is also a symlink, in a .wants directory.

7. Something Most Users Do Not Know

7.1 The Whole "Database" Is Just Symlink Names

SysV init has no registry, no database, and no config format for "which services start at boot". The entire answer is encoded in the names of symbolic links in the rcN.d directories. The letter (S or K) says start or stop, the two digits say the order, and the rest is the script name. That is all. You can read the complete boot plan for a runlevel with a plain ls, and change it by renaming or deleting links. It is beautifully transparent and, at scale, painfully manual, which is why every distribution wrapped it in tools like update-rc.d and chkconfig.

7.2 Runlevel Numbers Mean Different Things on Different Distributions

A common and dangerous surprise: the numbers 2 through 5 are only conventions, and the two big Unix families never agreed on them. On Red Hat-style systems, runlevel 3 is multi-user text mode and 5 adds a graphical desktop. On Debian-style systems, runlevels 2 through 5 are all the same full multi-user state by default. So a script or instruction that says "boot to runlevel 3 for no graphics" is correct on Red Hat and does nothing useful on Debian. Only 0 (halt), 1 (single-user), and 6 (reboot) mean the same thing everywhere.

7.3 init Really Does Supervise One Thing: getty

People say old init "did not watch its services", and that is mostly true, with one clear exception: the respawn action in inittab. Any line marked respawn is restarted by init the instant it exits. Its main use is the getty login prompts on the virtual consoles: log out, and init immediately starts a fresh prompt. This tiny piece of supervision has always been in init; systemd simply generalised it to every service with directives like Restart=on-failure.

7.4 Why the Old Boot Was So Slow

SysV init ran the S scripts in a runlevel strictly one at a time, in number order, each finishing before the next began. If a network mount was slow, everything behind it simply waited. Modern hardware can start dozens of independent services at once, but SysV init had no idea which services were independent, so it could not overlap them safely. This single fact (serial startup) is the clearest reason a big SysV server could take minutes to boot while an equivalent systemd machine takes seconds: systemd reads the dependencies and starts everything it safely can in parallel.

7.5 On Your systemd Machine, It Is All a Polite Illusion

Run service cron restart on a current Ubuntu or Debian box and it works, printing "via systemctl". There is no SysV init running at all. systemd ships a generator that reads any leftover /etc/init.d scripts at boot and turns each one into a temporary unit on the fly, and it provides drop-in replacements for service, telinit, runlevel, and even a mapping from runlevels to targets (runlevel 3 becomes multi-user.target). The whole SysV surface is kept alive as a courtesy so decades of scripts and habits keep working.

7.6 How the Kernel Finds init in the First Place

Before any of this can happen, the kernel has to locate an init program to run as PID 1, and it does so by trying a short list of fixed paths in order. The first one that exists and runs, wins:

1. /sbin/init      the normal place (a symlink to systemd today)
2. /etc/init        an older location, tried next
3. /bin/init        another fallback
4. /bin/sh          last resort: just give a shell

If none of them can be run, the kernel gives up with a panic, because a system with no PID 1 cannot go on. This list is also why a broken init is recoverable. You can tell the kernel to skip it entirely by adding an init= option to the boot command line in GRUB:

init=/bin/bash     boot straight into a shell as PID 1, no init at all

This classic rescue trick hands you a root shell before any service or even the real init starts, which is exactly what you want when a bad configuration stops the machine from booting normally. It works on any Linux system, SysV or systemd, because the choice happens in the kernel, one step before init runs.

9. Common Mistakes

9.1 Myth versus Reality

9.2 Other Traps to Avoid

• Editing rcN.d links by hand. It is easy to break the order or forget the matching K link. Use update-rc.d or chkconfig instead.
• Trusting a stale PID file. If a daemon dies without cleaning up, the old PID may now belong to another program, and a stop can kill the wrong process.
• Forgetting the LSB header on a new script. Without it the enabling tool cannot place the service correctly in the boot order.
• Assuming init 0 is a safe test. It halts the machine. On a remote server that means you have just shut it off with no easy way back.
• Expecting logs in the journal. A pure SysV service writes wherever its script sends output, often a file in /var/log or nowhere at all; there is no unified journal to search.
• Editing an init script that systemd has replaced with a native unit. If a real .service exists, systemd uses it and ignores the old /etc/init.d script, so your edits appear to do nothing.