I'm not sure what you're asking.

On any system, something has to start "first", and be in charge of figuring out what the heck happens next. On modern Linux systems (and I'm oversimplifying massively), the hardware hands off to the kernel which launches some kind of init system the first userspace thing. That could be sysvinit or upstart or s6 or systemd or any number of other things. You could write it in any language, though the nature of when it has to launch strongly incentivizes writing it in some kind of compiled language so you aren't having to make sure the right interpreter bits are in place first.

That thing then, depending on its level of complexity, gets to handle things like "what else do I launch" and "what order to I launch it in" and "what do I do if a service I started stops on its own".

Beyond that, your life is way easier if more than one distro uses the same thing to do this, so that an upstream package author can write "this is how an init system launches my service" and distro maintainers can use that, vs having to create and maintain their own scripts for how their init system launches a service.

So, the "point" of init systems is "something has to be in charge of userspace".

Sorry, I guess my question wasn't "why does the tree need a root process" but "what is the critical feature that makes it worth using these tools instead of the dumbest possible alternative?"

So the dumb response to your questions is if I have a list of services: "what else do I launch?" everything, "what order do I launch it in?" launch it all at the same time, "what do I do if a service I started stops on its own?" restart it. I typoed, but I really meant my first sentence verbatim: suppose init is a bash script that just does:

    (while true; do service1 &> log1.txt ; sleep 5; done) &
    (while true; do service2 &> log1.txt ; sleep 5; done) &
    (while true; do service3 &> log1.txt ; sleep 5; done) &

On a desktop I'm not starting/stopping systemd services ever. Every process I launch is managed by the window manager. On servers it's mostly the same: start everything at boot, then the server does its thing until shutdown. On more traditional mutable SMB shared servers I can imagine sysadmins going in and stopping/starting/adding new systems, but I feel like that use case is gradually growing less important.

It's largely touted that systemd's killer feature is that it represents services as a graph. But why is it important that it operates as a graph? Why is ordering startup important? Or does that not matter, and the real reason systemd matters is that it makes packaging easier (as you said, and as I said) and it has lots of built in conveniences? I have my guesses, but I'd like outside opinions.

This very much reminds me of how old Slackware systems used to operate. It was workable, but had a number of problems:

(1) I want to stop "service1" for a few minutes, without affecting other services, how do I do this?

(2) I want to disable "service1" completely, or pass it an extra parameter, without affecting other services. How do I do this? Note you cannot edit the init file and restart, this'll restart all the other services as well.

(3) I just typed "my-package-manager install service4", and I want service4 to start right away (and naturally have full functionality - keep restarting on failure, save logs, etc..). How do I do this?

(4) service2 had a emitted too many log lines, and my log disk is full. How do I clean existing logs without restarting the service? (Note even if you remove the file, it'll still take up the disk space)

(5) You were debugging service3 performance, and noticed it has printed "ERROR out of foobars" to its log but didn't print the timestamp.. When did this happen?

(6) service2 needs to be started after NFS volume is mounted. service3 is responsible for cpu fans and should be started as early as possible. service1 will re-generate the userdb if the data directory is missing, so it should not be started automatically if that's the case.

(7) new version of service1 changes command-line and default restart interval. How do I apply this change to my heavily customized startup file?

I could go on and on. All of those are real problems, and before systemd, they were solved with tons of bespoke code. Either C/C++ code (making a trivial daemons complex beasts), or shell code of init system, with was typically highly distribution dependent. And of course it was fragile and full of bugs.

Thanks! This is exactly the sort of stuff I was looking for.

So maybe this is too reductive, but basically:

- Tools for mutation of a running system

- Dealing with hard dependencies that don't cause errors when unavailable (like nfs in your example, or fan control, but also enumerating devices as I mentioned earlier, or for security, firewall rules since firewall starts entirely permissive)

- Standard packaging (edit: er, composability via standard packaging, or modularity with standard packaging for modules)

I think the logging stuff (datetimes, clearing, etc) is probably more the domain of a logger like journald, whose purpose seems is more concrete to me.

> Why is ordering startup important?

This is pretty fundamental stuff. You can't run a program if the disk that it's sitting on hasn't been made accessible yet. You can't start a network service that listens on a certain IP address if that IP address hasn't been configured yet, or if the destination for service logs isn't ready, or if our service needs to talk to some other service like a database which isn't running yet. Etc etc. Booting up a modern system to a graphical environment requires hundreds of things to happen in the right order.

As for everything else, the project announcement blog post from 2010 does a pretty great job summing up the shortcomings of doing "the simplest possible thing": https://0pointer.de/blog/projects/systemd.html . You can certainly still do things that way if you want, but most people value the benefits gained from a more intricate approach.

Ah, thanks for the link! So it has an interesting point, which is socket/device activation. And services that aren't started immediately could also have dependencies you don't want to start immediately.

I can see that being important for a desktop, where you're plugging/unplugging stuff and want startup to be fast.

> You can certainly still do things that way if you want

I think you're putting words in my mouth.

Sorry, I didn't mean you specifically. I meant, if someone values simplicity above all else, they can choose an init that matches those values (like the one you described). Your approach is perfectly valid given that set of values.

Debian and other distros asked their userbase which values to prioritize, and the users chose what systemd provides. Hope that helps explain "why does systemd exist / why have most distros chosen it?"

Oh, that answer is bigger but pretty boring: the dumbest possible alternative doesn't account for the complexity of real life systems.

Some examples:

On your desktop, while you launch programs through the window manager, things like the window manager itself, and also the network daemon, and time-keeping daemon, and the daemon that logs go to, etc etc, all need to be spun up by something.

Some of those daemons should restart themselves if they crash, and some of them shouldn't.

Some of those daemons misbehave, so it's nice to be able to tell them "don't eat all the RAM" that rendaw is trying to use to do whatever you're using the desktop for.

Some of those services shouldn't start until it's the right time in the sequence, but also you want booting to be fast, so where we can be parallel, it's nice to be parallel (this is where the graph comes in). And on the flip side, some of those services need to restart if a service they depend on restarts.

I've run s6 (the project built by skarnet, the author of the original post here) on a variety of systems. I would highly recommend it as a very high quality example of the kind of minimalist init system you're envisioning. And likewise, I'd encourage you to try it out! It's possible you'd find that for some/all of your use cases, the value of simplicity outweighs the value of the conveniences. But the reason that systemd has seen so much success on modern Linux distros is that for the average distro and average user, the conveniences in terms of functionality and standardization are worth it.

Okay, I assumed there are services that shouldn't restart if they crash given that that's the systemd default, but do you have an example? I don't think I've ever encountered any, and I can't think of a situation where you'd want that.

If you have access to a systemd-based system, you can try:

    grep -R Restart /etc/systemd/ /usr/lib/systemd/

And examine the returned unit files. But one of the examples I see is things like the SSH server (useful so you don't lose management access to a remote server), the virtual terminal process for local console logins, etc.

One of the examples from my world is generally databases. If I’m running a large or clustered DB, I probably don’t want it to just blindly restart on a crash.

Oh interesting, here we have mysql on auto restart and IME it's critical to reliability since sometimes stuff happens and mysql goes down on a node.

I guess different databases might require more manual intervention to recover?