Boot Process: Init

The kernel starts the first user-space process as PID 1 in a PID namespace. On a full Linux system, this init process establishes the service environment. In a container, PID 1 can instead be a small init wrapper or the application itself, but it still has special signal and child-reaping responsibilities.

Responsibilities of PID 1

An init system commonly:

• starts and supervises services, logins, mounts, and other units of work
• orders work according to dependencies and configured target state
• adopts and reaps orphaned child processes
• responds to service failures according to policy
• coordinates orderly shutdown and reboot

The exact boundary varies. Device management, networking, logging, and scheduled tasks can be separate programs supervised by init rather than code built into PID 1.

CheckWhich responsibility is special for PID 1 in its PID namespace?

Compiling every application from source at each boot. Defining the disk's physical sector size. Adopting and reaping orphaned child processes.

System V Init and Runlevels

Traditional sysvinit uses configuration such as /etc/inittab and runlevel-specific startup and shutdown scripts. A runlevel represents an operating mode, but the meaning of numbered levels can differ by distribution. Script ordering is convention-driven and can be extended or parallelized by distribution tooling.

Do not infer a host's active init system merely because /etc/init.d/ exists; compatibility scripts can remain on systems whose PID 1 is another implementation.

CheckWhat does a System V runlevel represent?

A kernel version number selected by the bootloader. A configured operating mode associated with service actions. A filesystem's current inode usage percentage.

Event- and Dependency-Based Systems

Upstart introduced an event-driven job model and was used by older Ubuntu releases and some other systems. It is now primarily of historical or legacy operational interest.

systemd is widely used by current general-purpose distributions. It models services, sockets, mounts, timers, devices, targets, and other resources as units. Declarative dependencies and activation mechanisms let independent work proceed concurrently while preserving required ordering.

Other active init and supervision designs include OpenRC, runit, s6, and BusyBox init. “Newest” is not a useful compatibility rule; identify what the actual system runs and use its documentation.

CheckHow does systemd represent managed resources such as services and mounts?

As MBR primary partition entries. As hard links to PID 1's executable only. As units with dependencies and activation relationships.

Identifying the Running Init

Inspect PID 1 rather than guessing from installed files:

$ ps -p 1 -o pid,comm,args=
$ readlink /proc/1/exe

Permissions, containers, and namespaces affect what you see. A command run inside a container reports that namespace's PID 1, not necessarily the host init. Once identified, use its native status and log tools instead of mixing commands from another init family.

CheckWhy is inspecting PID 1 better than checking whether a legacy script directory exists?

PID 1 always has the same executable name on every Linux system. Compatibility files can exist even when another init implementation is running. Legacy directories are automatically deleted at every boot.

Summary

You can now explain init as a role rather than one mandatory implementation.

1. Relate PID 1 to service initialization, reaping, and shutdown.
2. Recognize System V runlevels as distribution-defined operating modes.
3. Relate systemd resources and dependencies to units.
4. Inspect the live PID 1 in the relevant namespace before choosing tools.