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.

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.

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.

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.

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.