2.6 SysVinit Runlevels, Telinit & System Shutdown (101.3)

2.6 SysVinit Runlevels, Telinit & System Shutdown

Quick Summary: Classic Linux distributions utilize the SysVinit (System V Initialization) daemon as PID 1. SysVinit structures system states into discrete numeric runlevels (0 through 6) controlled by /etc/inittab and orchestrated through runlevel directories (/etc/rc[0-6].d/) containing kill (K*) and start (S*) scripts. Administrators switch runlevels using telinit or init, inspect states with runlevel, and safely power off or reboot systems using shutdown, reboot, poweroff, and wall.

---

1. Classic SysVinit Architecture & Runlevels

Under SysVinit, when the kernel finishes initializing, it starts /sbin/init (PID 1). Init reads /etc/inittab to determine the default runlevel and executes shell scripts sequentially to bring up networking, daemons, and login consoles.

The Standard SysVinit Runlevels

---

2. Mapping SysVinit Runlevels to Systemd Targets

Because modern Linux systems utilize systemd, systemd provides target units that maintain full backwards compatibility with SysVinit runlevels.

3. SysVinit Configuration: /etc/inittab

The configuration file for SysVinit is /etc/inittab. Each line defines how init behaves during boot and upon switching runlevels.

Syntax Format

id:runlevels:action:process

• id: A unique 1 to 4 character identifier for the entry (e.g., id, si, l3, 1, tty1).
• runlevels: A list of numeric runlevels for which this entry is active (e.g., 35, 0123456, or left empty if applicable to all).
• action: Specifies how init executes the command in the process field.
• process: The exact shell command or binary executable to run.

Standard /etc/inittab Actions

Exam Tip — Setting Default Runlevel in /etc/inittab: To configure a SysVinit server to boot into text multi-user mode by default, set the initdefault line to:

id:3:initdefault:

Never set initdefault to 0 (system immediately powers off on boot) or 6 (system enters an infinite reboot loop).

4. Runlevel Switching & Inspection Commands

1. The runlevel Command

runlevel queries the /var/run/utmp database to display the previous and current runlevels separated by a space.

$ runlevel
N 3

• The first character represents the previous runlevel (N indicates "None", meaning the system booted directly into this runlevel without switching).
• The second character represents the current runlevel (3).
• If the administrator switched from runlevel 3 to runlevel 5, runlevel outputs: 3 5.

---

2. telinit and init

telinit sends control signals to /sbin/init instructing it to transition to a new runlevel or re-examine configuration files.

# Switch to full multi-user command-line mode
sudo telinit 3
# or
sudo init 3

# Switch to graphical desktop mode
sudo telinit 5

# Switch to single-user maintenance mode
sudo telinit 1

# Power off the machine immediately
sudo telinit 0

# Reboot the machine
sudo telinit 6

# Force init to re-read /etc/inittab without changing runlevel
sudo telinit q
# or
sudo telinit Q

# Re-execute the init binary (useful after library/init updates)
sudo telinit u

5. Init Scripts & Execution Structure

SysVinit manages service startup and shutdown using standard shell scripts located in /etc/init.d/ (or /etc/rc.d/init.d/).

Runlevel Directory Hierarchy

For each runlevel N (0 to 6), a corresponding directory exists: /etc/rcN.d/ (e.g., /etc/rc3.d/, /etc/rc5.d/). These directories contain symbolic links pointing back to master scripts in /etc/init.d/.

/etc/
├── init.d/                  # Master service scripts (sshd, networking, apache2)
├── rc0.d/ -> /etc/rc.d/rc0.d/  (Halt scripts)
├── rc1.d/                   (Single-user scripts)
├── rc3.d/                   (Multi-user CLI scripts)
│   ├── K10network -> ../init.d/network
│   ├── S10network -> ../init.d/network
│   ├── S50sshd -> ../init.d/sshd
│   └── S80apache2 -> ../init.d/apache2
└── rc5.d/                   (Graphical scripts)

Symlink Naming Conventions

• K<priority><servicename>: Kill (Stop) script. When entering the runlevel, init executes these scripts with the stop argument to terminate services that should not run in this runlevel.
• S<priority><servicename>: Start script. When entering the runlevel, init executes these scripts with the start argument.
• Priority Number (00–99): Two-digit integer defining execution order. Scripts are executed in ascending numerical order (S10network runs before S50sshd).

6. System Shutdown & Reboot Procedures

To prevent data corruption, open files must be flushed to disk (sync), processes must receive termination signals (SIGTERM followed by SIGKILL), unmount hooks must run, and filesystems must be unmounted cleanly.

The shutdown Command

shutdown brings the system down in a safe, controlled manner.

shutdown [OPTIONS] [TIME] [WALL-MESSAGE]

Time Argument Formats

• now: Immediate shutdown (equivalent to +0).
• +m: Relative time in m minutes from now (e.g., +15 for 15 minutes).
• hh:mm: Absolute 24-hour clock time (e.g., 23:30 for 11:30 PM).

Crucial shutdown Command Options

• -h: Halts or powers off the system after shutdown.
• -P: Powers off the hardware (halts and turns off ACPI power).
• -H: Halts the operating system without cutting hardware power.
• -r: Reboots the machine after clean shutdown.
• -c: Cancels a pending scheduled shutdown.
• -k: Fake shutdown / warning mode. Sends broadcast warning messages to all logged-in users via wall without actually shutting down or rebooting the system.

# Schedule a reboot in 10 minutes with a broadcast warning
$ sudo shutdown -r +10 "System reboot for kernel upgrade. Please save all work!"

# Schedule a poweroff at 11:00 PM tonight
$ sudo shutdown -h 23:00 "Nightly scheduled maintenance shutdown"

# Cancel the pending shutdown
$ sudo shutdown -c "Maintenance cancelled. The system will remain online."

# Broadcast a dry-run test warning without shutting down
$ sudo shutdown -k +5 "Testing emergency notification system"

---

Direct Shutdown Utilities

• reboot: Immediately signals systemd/init to reboot the machine (reboot -f forces immediate reboot without notifying init).
• poweroff: Immediately powers down the hardware.
• halt: Halts the CPU instructions.
• wall [message]: Broadcasts a message to standard output on all currently logged-in user terminals (tty and pts).

  echo "Emergency: Storage server offline in 2 minutes" | wall
  

---

7. acpid: Turning Hardware Power Events into Shutdowns

Objective 101.3 explicitly lists awareness of acpid, and it is the only piece of that objective that has nothing to do with a command you type. It matters because it answers a question the rest of the objective does not: what happens when somebody physically presses the power button?

ACPI (Advanced Configuration and Power Interface) is the firmware standard through which hardware reports power events — power button pressed, lid closed, AC adapter unplugged, thermal trip point crossed. The kernel receives those events, but the kernel has no policy about what they should mean. acpid (the ACPI event daemon) supplies that policy from user space.

The event chain:

Power button pressed
  → firmware raises an ACPI event
  → kernel ACPI subsystem publishes it on /proc/acpi/event (or via netlink)
  → acpid reads the event
  → acpid matches it against a rule in /etc/acpi/events/
  → acpid runs the action script, typically /etc/acpi/powerbtn.sh
  → the script calls `shutdown -h now` (or hands off to the desktop session)

A typical rule file is only two lines:

# /etc/acpi/events/powerbtn
event=button/power.*
action=/etc/acpi/powerbtn.sh "%e"

# Confirm the daemon is running
systemctl status acpid

# Watch raw events while you press the power button or close the lid
acpi_listen

Exam Rule: If acpid is not running (or its handler is missing), pressing the power button on a headless server may do nothing at all, or may cut power abruptly without a clean unmount — which is exactly why the objective pairs it with shutdown. On modern systemd systems systemd-logind handles button events directly through HandlePowerKey= in /etc/systemd/logind.conf, and acpid is only needed for events logind does not claim. Know the name, the daemon's role as the user-space policy layer for kernel ACPI events, and /etc/acpi/events/ as its rule directory.