[StreamBright]

Well yes and no. I like the good parts of SystemD (not the parts this video is talking about).

For me there are 3 things that SystemD gets right:

- no shell scripts for service configurations

- no forking services (no need for daemon mode anymore)

- logging and service management is tightly coupled (this is arguably good with some bad parts, required CPU for logging with systemd is not great)

And the rest is just pure madness.

- DNS (but whyt?)

- NTP (but why????)

- system limits (seriously, da f???)

- pid 1 should be a very simple service (More: https://ewontfix.com/14/)

I have spent 25 years on Unix, so I guess I understand the concepts.

[larschdk]

DNS + NTP are completely optional, but you get really good integration with systemd-networkd's DHCP client if you use them. Switching network is completely seamless, and the resolver updates fully automatically (direct DNS and NTP are blocked in many networks, sadly). Also, you get something that works out of the box, with essentially 0 configuration. You can't even install a system today over the internet without setting the time, and systemd-timesyncd does it with 0 configuration.

[Arch-TK]

> - no shell scripts for service configurations

Other than "sysvinit based init had horrific shell scripts with 100 lines of repeated nonsense", given that almost every alternative to systemd which still uses shell scripts needs around 2 lines of shell per service (including the shebang) what exactly is the issue with shell scripts (if all they do is run a wrapper which sets up the environment of a program or the program itself)?

> - no forking services

When I used archlinux these were extremely common and I used archlinux as recently as last year.

> - logging and service management is tightly coupled (this is arguably good with some bad parts, required CPU for logging with systemd is not great)

So runit handles spawning a log daemon before the service is started to ensure all log entries are kept and comes with a really simple yet extremely powerful log daemon (but obviously you can use almost anything else including cat if you want). It manages to integrate logging tightly into service supervision while being maximally flexible and decoupled. What do you think about this?

[StreamBright]

OK I bite. Nothing is wrong with shell scripts. However, I would like to know if something _wont_ work. Shell scripts do not have this feature. You know if something does not work when you run it. There might be external dependencies missing or other very typical problems. If we have a way to push all of these to "compile time" it is an improvement. I also spent many years in the land mines of implicit overrides in shell script hells and thank you but no. As a good example you can have how people try to set JVM parameters in a big data project using shell scripts. I it is absolute insanity. Same thing in init scripts. Did you implement reload or restart? Is stop actually doing something or a noop. And so on.

If there is only one thing that I could keep from systemd, it would be the use of unit files instead of shell scripts.

The rest is your observations, nothing to disagree or agree with.

[Arch-TK]

> However, I would like to know if something _wont_ work. Shell scripts do not have this feature.

... Does systemd?

I still have endless problems with unreliable service startup and I've read all the documentation, have done all the debugging and asked all the people I could find.

> I also spent many years in the land mines of implicit overrides in shell script hells and thank you but no.

I'm not sure what you mean by this.

> Same thing in init scripts. Did you implement reload or restart? Is stop actually doing something or a noop.

So this is linux sysvinit style init scripts, OpenRC doesn't have this issue (as far as I can tell) and definitely I've never had to ask myself any of these questions when using daemontools or runit. Maybe you should familiarize yourself with how some modern non-linux-sysvinit inits work because they're certainly extremely functional, reliable and clear.

> If there is only one thing that I could keep from systemd, it would be the use of unit files instead of shell scripts.

I've actually considered this and I think it would be incredibly trivial to make a unit file parser which you can call from a shebang which would do this kind of thing. You could even have it fork off the parser to run it unprivileged. I think I'll try writing it sometime soon. You could even integrate all the namespacing, cgroups and lots of the other features systemd provides into it.

[1vuio0pswjnm7]

I use daemontools instead of runit. What am I missing.

multilog is the simplest (smallest) and most versatile log rotating daemon I have found.

[Arch-TK]

A few extra features, but you probably don't need them. I use svlogd because I use runit and I use runit because it happens to be supported by my distro.