[shevy-java]

Agreed. But you still need to know what to enable/disable, so more complexity is the outcome.

> And prod deployments breaking... Well I guess that never happened with those best-managed sysv init scripts?

Which of these two has the larger surface area? I would assume there are more problems in systemd simply because it has a lot more code.

> Guys, pick your fights reasonably.

I don't see what is not reasonable here at all. Can you explain this? In particular I would like to see your explanation how more code means less issues, all other things considered being equal. And that's just the code - there are many additional issues, documentation, maintenance and so forth.

[gf000]

Not all code are equal.

There is an essential complexity you need, period. This is a fundamental truth that that can never decrease.

And init and service management is a generally hard problem - like a static approach wouldn't bring you too far, you have services activated at runtime, modules appearing, disappearing etc.

So it's a hard problem, yet many parts are repeating. A network service and a file system mount both require some kind of dependency management, parallelism with locks, logging etc. On top, a declarative approach is far better for such a dynamic system and that's exactly what systemd is.

OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.

[adrian_b]

Init scripts should not need significantly more than a few lines.

I do not think that I have ever used an init script longer than 1 page of text.

If bugs are feared, it is always possible to invoke a script written in another scripting language.

While some people like Python for this purpose, in the past I had good results by using scsh for complex scripts where one wants to avoid bugs.

"scsh" is a Scheme dialect specially designed for replacing shell scripts, i.e. where you have a convenient syntax to express the features of a shell scripting language, like writing command pipelines, file redirections, etc.

Even a zsh script can avoid the most frequent errors from bash scripts, which are caused by the incorrect use of quotation.

With any scripting language, it is possible and recommendable to use strictly declarative init scripts, which only contain definitions of variables and parameters for invocations, separating the procedure definitions in distinct files, which are common to any installation and which are not modified for a custom configuration.

Even when it may be desirable to implement some functions of the init system in binary executables, those must be extremely simple, as demonstrated by the small executables included in the daemontools of Daniel J. Bernstein, and not like the big monstrosities of Systemd.

[simoncion]

> OpenRC gives some of this, but bash is an abomination and anything larger than 2-3 lines will have bugs. I don't really see what it's giving you over an open-source binary that parses trivial .ini-like files that have pretty good portability across systems.

Hey, hun. Here's an OpenRC service file that's nearly as small as it can get. [0] I don't know about you, but that OpenRC service file looks a whole hell of a lot like a Unit file to me. Do you disagree?

If you replace line 14 with

  supervisor=supervise-daemon

and remove the "-D" from 'command_args' to make avahi-daemon run in the foreground, then you don't have to deal with "icky" pidfiles, and you get daemon supervision and automatic restart on failure.

OpenRC also does parallel service start and stop. I've been using it for... ten years now with no problem.

[0] <https://github.com/OpenRC/openrc/blob/29f620c16036586c39ec17...>