VMware ESXi and vSphere Cluster Management

Understanding /etc/inittab and SysV Init Runlevels

Learn how SysV init uses /etc/inittab to select runlevels, run startup commands, manage transitions, and respawn critical processes.

/etc/inittab is the primary configuration file used by traditional SysV init implementations. It tells the system which operating state to enter, which commands to run during startup or state changes, and which long-running processes init should supervise.

This is a legacy Linux administration topic. Many current distributions use systemd instead, so first identify which program is running as PID 1.

What Are SysV init and /etc/inittab?

init is the first userspace process started by the Linux kernel. It traditionally runs as process ID 1, or PID 1. After the kernel has initialized basic hardware and memory management, it starts init to continue userspace startup.

On a SysV-init system, init reads /etc/inittab. The file contains records that can:

• Select the default runlevel.
• Run early initialization commands.
• Run commands when the system enters a particular runlevel.
• Start login processes and restart them if they exit.
• React to events such as the secure attention key sequence or power-failure notifications, when supported.

A modern systemd host may not have this file, may ignore it, or may provide it only for compatibility. Never assume that editing /etc/inittab changes a system until PID 1 has been identified.

Where /etc/inittab Fits in the Boot Sequence

1. The bootloader loads the Linux kernel and an initial filesystem.
2. The kernel initializes the system and starts the first userspace process.
3. SysV init runs as PID 1 and reads /etc/inittab.
4. Init determines the selected runlevel, usually from an initdefault entry unless a boot-time override was supplied.
5. Startup entries for that state invoke commands or runlevel-control scripts.
6. The runlevel framework starts and stops services appropriate to the selected state.
7. Login processes such as getty provide console or terminal login prompts.

A common design is for /etc/inittab to call a shared rc script. An rc script is a runlevel dispatcher that starts or stops services for a requested operating state. The service details usually live in the rc framework and scripts under paths such as /etc/init.d, rather than entirely in /etc/inittab.

Runlevels

A runlevel is a predefined operating state. The runlevels traditionally use the numbers 0 through 6, but their exact meanings vary between distributions.

Runlevels 0 and 6 are operational commands rather than normal working states. Selecting either as the default can cause a system to power off or reboot repeatedly.

The /etc/inittab Entry Format

Each traditional entry has four colon-separated fields:

id:runlevels:action:process

Comments typically begin with a leading hash character. Field order and colon placement are significant:

# This entry is ignored
l3:3:wait:/etc/init.d/rc 3

An omitted or blank runlevels field is not universally equivalent to every possible runlevel. Its meaning is determined by the action and the particular init implementation. For special actions such as initdefault, consult the implementation's documentation rather than guessing.

The id Field

The id field is a short label that init uses to identify an entry. Traditional SysV implementations commonly limit it to one through four characters. Labels should be unique within the file.

Use labels that communicate purpose, especially for supervised processes. For example, tty1 can identify a console login process, while l3 can identify a runlevel dispatcher entry. The label l3 is not itself runlevel 3; the runlevel is specified in the second field.

The runlevels Field

This field contains the runlevel numbers for which an ordinary entry is active. For example, 35 means that the entry applies to both runlevels 3 and 5. An entry with 3 applies only to runlevel 3.

Actions such as initdefault receive special handling. They select a startup state rather than acting as ordinary commands that run every time a listed runlevel is entered.

The action Field

The action tells init when to execute the process and whether to wait, restart it, or treat the record specially.

Real files may also contain ondemand, powerwait, powerfail, powerokwait, and kbrequest. Availability and exact semantics differ between SysV init implementations.

The process Field

The final field contains the executable command, script, and arguments. Prefer a valid absolute path and verify that the target exists, has suitable permissions, and accepts the supplied arguments.

l3:3:wait:/etc/init.d/rc 3

Here, init invokes /etc/init.d/rc with 3 as its argument and waits for the dispatcher to finish. A shell wrapper can be used when shell syntax is required, but quote arguments carefully and understand which user, environment, and working directory init supplies.

job:3:once:/bin/sh -c '/usr/local/sbin/job --mode safe >>/var/log/job.log 2>&1'

Redirection and shell operators are interpreted by the shell only when a shell is explicitly used. They are not automatically interpreted as shell syntax by every init implementation.

Choosing the Default Runlevel

An initdefault record selects the runlevel used during normal boot when no runlevel override is supplied. It selects a state; it does not launch a program, so its process field is normally empty.

id:3:initdefault:

This example selects runlevel 3. After selection, entries applicable to runlevel 3 commonly invoke the rc framework, which then starts the services configured for that state.

To identify the configured default on a SysV system, inspect the file as an administrator and search for an initdefault action:

grep -n '^[^#].*:initdefault:' /etc/inittab

Before changing it, make a backup, confirm the distribution's runlevel meanings, and preserve a console or recovery path. A remote change can remove networking, stop remote login, or place the machine in single-user mode. On production hosts, arrange out-of-band access and a rollback plan.

Runlevel Transition Entries

Entries associated with a runlevel are evaluated when init enters that runlevel. A common configuration has one dispatcher entry for each state:

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
#l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

The commented l4 line is ignored. The other records call the same rc dispatcher with different numeric arguments. The dispatcher and service scripts determine which daemons start or stop, their ordering, and their dependencies.

Supervising Processes with respawn

The respawn action tells init to keep a process available. Init starts the command, detects when it terminates, and starts it again. A traditional virtual-console login entry might look like this:

tty1:2345:respawn:/sbin/getty 38400 tty1

getty displays a login prompt and normally remains running while the terminal is in use. When a user logs out or the getty process exits, init respawns it so the console is ready for another login.

Do not use respawn for a command that exits immediately. A bad path, invalid argument, missing permission, or one-shot program can create a rapid failure loop. Implementations may rate-limit restarts or temporarily disable a repeatedly failing entry, but this behavior varies.

Administration and Safe Changes

1. Confirm that the host actually uses SysV init.
2. Back up the existing file and preserve a root console or recovery method.
3. Check every field, colon separator, command path, argument, and executable permission.
4. Validate the relevant script independently when possible.
5. Ask init to reread its configuration using the supported mechanism.
6. Review logs and confirm that expected processes and services are running.

A common SysV-style request to reread /etc/inittab is:

telinit q

Some implementations use an equivalent init reload or re-exec operation. Rereading the configuration is different from changing runlevels: it loads updated records but does not, by itself, request a transition to another operating state.

Changing runlevels is disruptive. For example:

telinit 1

The command runlevel can report the previous and current runlevel where SysV-compatible reporting is available:

runlevel

Identifying Modern Init Systems

Check PID 1 before applying SysV-specific instructions:

ps -p 1 -o pid,comm,args

If the command shows a SysV init implementation, /etc/inittab may control startup. If it shows systemd, the host generally uses targets and unit files instead.

On a systemd host, check the default boot target with:

systemctl get-default

This is the modern equivalent for inspecting the normal boot destination; it does not edit or activate /etc/inittab.

Troubleshooting

Changes Have No Effect

• Inspect PID 1; the system may use systemd or another init system.
• Check whether the edited line begins with #.
• Verify the four fields and all colon separators.
• Ask the correct init implementation to reread its configuration, if required.

The System Boots into an Unexpected Mode

• Review the initdefault entry.
• Check whether the bootloader or kernel command line supplied a runlevel override.
• Confirm the distribution-specific meaning of the selected runlevel.
• Use console or recovery access before making another change.

A Respawned Process Repeatedly Restarts

• Run the command manually in a safe environment.
• Check its path, arguments, permissions, dependencies, and logs.
• Use once or wait when the command is not intended to remain running.

Startup Pauses at a Runlevel Entry

• A wait or bootwait command may be hanging.
• The rc script may be missing, non-executable, or failing because of a dependency.
• Verify the command path and permissions, review logs, and test the script cautiously outside a production transition.

Remote Access Is Lost

• The selected state may not start networking or remote-login services.
• The host may have entered single-user mode.
• Use out-of-band console access, restore a known-good configuration, and verify service startup sequencing before rebooting.

Exam-Relevant Summary

• /etc/inittab is read by traditional SysV init, commonly running as PID 1.
• The record format is id:runlevels:action:process.
• initdefault selects the normal boot runlevel and normally has no process command.
• sysinit handles early initialization; boot and bootwait run boot commands; wait runs an ordered command during a runlevel transition.
• respawn restarts a process after it exits, making it suitable for getty processes but dangerous for commands that terminate immediately.
• Runlevel meanings are conventional, not completely universal: 0 usually halts, 1 provides maintenance mode, 3 commonly provides text multiuser operation, 5 commonly provides graphical operation, and 6 reboots.
• Runlevel entries often call a shared rc script; service start and stop logic usually lives in that rc framework.
• Reloading inittab is not the same as changing runlevels.
• On systemd systems, inspect targets and units instead of assuming that /etc/inittab is active.

For a compact reference, see /etc/inittab.