I mean, you (or somebody) need to write a short bash script for each service on sysv, and adding cgroup management to that isn't particularly hard. I just never understood how people find that more complex than a huge mess of unit files that transpile down to God-knows-what, but apparently people do.

The user services systemd offers are legitimately cool (though shepherd does it better), I've just never personally understood how people find it "simpler" as a system service manager.

Thanks for the clarification.

But I still don't get it; have you ever _seen_ a complete init script? These things are hundreds of lines long if you want to account for stuff like PID management and restart capability and isolation.

And you have to do that for every service on your system. And they are not even really portable.

It only gets that long if you include the LSB dependency nonsense. Look at Slackware's scripts and tell me where those hundreds of lines are hiding.

I've used this opportunity to look at some recent init files.

Here's one of the first I stumbled upon.

https://github.com/NagiosEnterprises/nagioscore/blob/master/...

It's 288 lines long; the LSB dependency nonsense is 8 lines of that.

Then I looked up one for Postgres;

https://wiki.postgresql.org/wiki/Lsb_conforming_init_script

This one is a whooping 356 lines long, LSB is again about 10 lines long, depending whether you count the header or not.

I don't think the "LSB dependency" argument holds water.

The irony is that a lot of the boilerplate from both, including that massive case...esac part, has been eliminatable for about 10 years. See https://unix.stackexchange.com/a/480897/5132.

These are not "recent" at all, which is part of the problem. The wiki page largely froze in 2010, several years before the init-d-script innovation; and the people maintaining the nagios script until around 2018 never even tried to make use of init-d-script.

It might well be that most of the boilerplate is a "solved problem" - then the question becomes; is this solution used at all? Let's have a look at a recent init file, from current Debian. I again just picked the first thing that I found, which was the openldap package:

https://packages.debian.org/bookworm/amd64/slapd/download

This init file too is over 200 lines long. I don't know how much of this is avoidable boilerplate, but evidently the Debian package maintainers either don't know about it or they lack the resources to implement it.

Okay. Would you mind explaining how you set up dependencies between the various services if you don't use the "LSB dependency nonsense"? What does Slackware use for that?

You write the shell commands that start them in the order you want them started in and run that from your rc system. I stg I have no idea why people find this so hard.

For me the hard part comes when you don't want these services run all the time, but only when needed.

How'd you do that?

Inetd, the software people mysteriously re-invent every decade or so

And then you don't have dependencies anymore, so you're back to square one.

I don't see how this is supposed to be more comprehensible or even "simpler" than a 12 lines unit file.

Several dozen unit files whose dependencies need not be listed in the files themselves, you mean. Which is why it's a step backwards in terms of simplicity.

You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.

> Several dozen unit files whose dependencies need not be listed in the files themselves

Where else would you expect to declare the dependencies other than the file which defines the service? That's where I would expect to find (and add) the dependencies.

> You get the dependencies just like you do with any other socket activation. Web request starts the web server, which connects to and starts the application server, which connects to and starts the data store.

Fair enough!

But dependencies can also be expressed by the location of a symlink