4 ms·

Kind of a non-sequitur, but what is actually the point of systemd (and other similar tools)? Like compared to just spawning a bash processes that run a critica

by rendaw 2y ago

Kind of a non-sequitur, but what is actually the point of systemd (and other similar tools)? Like compared to just spawning a bash processes that run a critical commands in a loop. I can come up with a couple functions, but none of them seem like core things, more like tangential benefits: - Startup ordering means you don't get log spam with "can't connect to X" until X starts - Certain dependencies like mounts look the same whether they're "running" or not, so not starting before the mount is important. Or like, if a program enumerates interfaces or something, making sure all the interfaces exist first (via a dependency). Of course, a program could do its own checks and possibly be more stateless about it. - As a standard, for packaging - you can distribute a service/socket file with your program and most distros can just plug it in and expect it to work (also thanks to having standard targets and directories). Otherwise it seems like an ugly declarative DSL for gluing programs together, which you could do in bash or python or whatever other language too. Is reducing log spam really the point? FWIW I do think systemd is better than the alternatives ATM...

akerl_ 2y ago
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".
- rendaw 2y ago
  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.
  - akerl_ 2y ago
    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.

by rendaw 2y ago

akerl_ 2y ago

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".

rendaw 2y ago
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.
- akerl_ 2y ago
  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.