The important things about Unix init systems aren't booting the system

February 19, 2022

A while back I said something on Twitter:

Thesis: pretty much anything can boot a Unix system in a static configuration. The important things about an init system are all of the aspects of what happens after booting and outside of a single boot.

In the very beginning, booting a Unix system was considered a very simple thing; the V7 /etc/rc is remarkably short. After a while various complexities showed up and because the problem wasn't well understood, people created various complicated systems for dealing with them. The complexities haven't gone away (a modern Unix has a lot more boot steps than V7 or BSD or System V), but we understand them and how to deal with them, and these days they're essentially mechanical. One demonstration of this is that there are a profusion of init systems and systems to start daemons, and every so often someone writes a new one in a relatively short amount of time and it works fine.

What that means is that both the challenging problems and the state of the art in an init system have moved on from just booting your Unix system in a static configuration. What really matters in init systems today and what distinguishes one from another is largely how they deal with operating the system and changing the system configuration. Changing the system configuration is the easier of the two sides to talk about; it's the area of how you change what happens in the next boot. How you add things, remove things, change exactly what happens, reorder things, and so on. Init systems can make this anywhere from easy to very difficult, and mostly they fall somewhere in the middle.

An init system is also potentially involved in operating the system. This is the area of telling you what is running, how the system state is, what did and did not start properly at boot (or afterward), and starting or restarting things for you while the system is running. Some init systems barely do this; others, such as systemd, are famously deeply entangled in it (for some good reasons). An init system can make this easy, difficult, or impossible. Because this area is newer and less well developed than changing what happens during boot, there seems to be more variation in Unix init systems here.

(For a long time no one even thought about having the init system involved in restarting daemons after boot or starting new ones. We have since discovered that this is a mistake.)

The days when one init system could boot your Unix better than another init system are basically over. Everyone is competent at that and it's not a hard problem any more. What matters to system administrators about Unix init systems is everything else.

(There are some specific environments running Unix kernels and 'Unix' systems where how the init system boots the system matters a lot. Some of these environments are very numerous, for example Android, but they don't really have system administrators.)


Comments on this page:

I think init systems evolved over time to also encompass the role of service manager (managing long running services aka daemons). A service manager runs better as PID1 for multiple reasons, and the notion of booting inherently implies that some services should be started too. The first paragraph of the description in the manpage for SYSTEMD(1) does a fairly good job at explaining this idea.

systemd is a system and service manager for Linux operating systems. When run as first process on boot (as PID 1), it acts as init system that brings up and maintains userspace services. Separate instances are started for logged-in users to start their services.

By Walex at 2022-02-20 15:20:31:

«no one even thought about having the init system involved in restarting daemons after boot or starting new ones.»

'man 5 inittab' https://manpages.debian.org/buster/sysvinit-core/inittab.5.en.html

«We have since discovered that this is a mistake»

But still 'init' does not have to be the process or service manager, and system software does not have to depend on the particular type of process or service manager. It is just how things have happened, and it would be easy to fix.

«init systems evolved over time to also encompass the role of service manager (managing long running services aka daemons)»

Oh please! The difference between process supervisors and service managers is really huge, and current process/daemon supervisors are not service managers, also because some of their authors have simply chosen to crassly ignore defining a service state model, and deliberately confuse process state with service state as a shortcut to fool the gullible.

http://www.sabi.co.uk/blog/21-one.html?210416#210416

Written on 19 February 2022.
« Ubuntu limits the console kernel log level even on servers
The history (sort of) of service management in Unix »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Feb 19 22:15:28 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.