I had a tiny little simple 2k init script that managed lxc containers.
It provided: * graceful start all at boot * graceful wait while shutdown all at shutdown * Enable/disable of individual containers * Start/stop of individual containers * Console access to individual containers * Query status (running/not/etc) of individual containers at any time. * Query status of entire metaservice at any time
All without any manager/monitor daemon either for the metaservice or the individual containers, and the script was tiny, maybe not even 2k.
Under systemd, it's not possible to have an init script that can just check the status and then exit again, and where the definition of status is whatever conditions you want to code up. There is no ExecStatus because the fundamental way systemd tracks upness or downness is not by performing an action to get the answer but by monitoring a process or a port or a file itself.
It requires a constantly running daemon of some sort that systemd can detect that it exited or is still running, or it requires one of a few other things that systemd just declares as all the possible options anyone can ever need. A port, a file, a process etc.
The way my script answered the up or down question was it examined a few things about the container and decided based on what it saw. There didn't need to be any persistent process dedicated to monitoring a container, or all containers. The containers could run any sort of processes and didn't have to do anything a certain way in order to coordinate. IE, a container might have it's own copy of init as it's pid 1, or just bash, or screen, or a random binary. The script got it's info from kernel cgroups info by reading files and making a determination based on the contents of the files. It did this on demand and only when requested. There was no server process to monitor, no pid/lock file to monitor, no port to monitor.
I'm not saying the cost of another process is so intolerable, I'm saying you can't actually do whatever you might want to do. You can only do that which the lord hath provided for.
In a sysv script, you are free to code up whatever unpredictable logic you may happen to need, without the init author from 50 years ago having to predict what your needs will be and providing some managed limited answer for those specific predicted needs.
Init not only doesn't care what you write in your script, it doesn't even care if it's a script at all. It doesn't have to be sh or even any scripting language, it could be a binary.
The joy and relief of systemd is the relief of "everything would be so much simpler if everyone just did exactly the same thing", which is the same as saying if everyone else just did what I say.
Here's how you know systemd's claim to being a good citizen is bs: Why can't I run systemd as just another service that isn't pid 1?
I would have had far less problem with systemd merely existing in the world if it were like say xinetd where it could be run as a service that managed other services that wanted it, but was not pid 1 because I happen to want init, or any other thing of my choice to be pid 1, for whatever my reasons are, and systemd nor Poettering nor anyone else has any right to know or care what those reasons are, certainly not to decide for me that they are not valid.
systemd presumes to know all the possible valid ways any service could operate, and any service that isn't covered is conveniently by definition invalid or insane, and so doesn't matter. Systemd is tight coupling. In every other aspect of IT, tight coupling is recognized as inflexible bad architecture.
And this is all just the process/service management parts. The binary logs are a whole other example of tight coupling. It's a pattern.
