In 20 years of managing Linux systems, I can probably count on one hand the time I saw an init script that was written properly unless it was provided by the distro maintainers (and often not then either). That is, it included all the expected options for the service, it correctly handled pid files for daemons that for whatever reason doesn't do it themselves, it handled reload's gracefully, and so on.

Good riddance to init files.

If these people want to keep people from using systemd, they need to come up with a better alternative.

I read your answer like this:

No newbie sysadmin should touch init scripts because they can't handle it.

Isn't it about damn time we go from overly complex to what makes sense?

“The only way to control chaos and complexity is to give up some of that control”

>No newbie sysadmin should touch init scripts because they can't handle it.

There's a lot of things newbie sysadmins are going to be bad at. I wouldn't expect them to come in and architect an infrastructure that will be handling millions of events per second, either. Nor would I expect them to be able to perform a deep dive and become performance engineers.

But sysvinit doesn't have to be the answer. I'm an Illumos guy. The SMF implementation is excellent, moves away from init scripts, and still doesn't throw the baby out with the bathwater like systemd does.

If I was interested in giving up control for the sake of reducing complexity, I'd go back to being a Windows sysadmin so I can click next on wizards and run dcpromo all day.

Without taking a position on the larger issue, with init scripts, another sysadmin could always figure out what the junior sysadmin did.

Jr: "I edited some init file."

Sr: "Which one?"

Jr: "I forget."

Sr: "Oh." sorts /etc directory by time "Oh, I see what you changed. That is wrong because of $REASON. You should do $CORRECT_THING instead."

Jr: "Okay, thanks for letting me know."

Sr: "We were all new guys once."

You can do that with systemd too -- service files are still just ordinary files; they're just "10 lines of info that matters" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate" :P

More like "10 lines of info that matters + I don't know/no reason to look at that" instead of "10 lines of info that matters + 90 lines of inconsistently implemented boilerplate"

Saying that systemd service files are complicated because you need to take systemd's internals into account is like saying sysv init scripts are complicated because you need to look at the source code to "cat" and "grep"; ie, no :P