Maybe it is just me, but I don't really look for the init script to provide me a status on whatever it is that it inited. "OK" or "FAIL" is good enough in that specific context. It is the services' job to provide me with information on how it failed (or succeeded, or partially failed) through an easily and always accessible logging mechanism.
Different services have different failure modes with nuances that can never be generically captured by whatever means you chose to launch the service, in any kind of meaningful way. When a Database service stops serving data, my first though isn't "Lets see what the init system thinks", my first thought is "Lets see what I can find in various Database service logfiles" which will, 99.9% of the time, be something specific to the database service.
Inits' job in my view is "start this, and get out of the way". "Start this", and do logging, and do DNS/DHCP/manage-daemons/manage-restarts-on-fail/manage-the-fs/here-is-a-kitchen-sink/do-you-want-fries-with-that/oh-yes-and-here-is-NTP isn't what I am personally looking for in an init system, and - frankly - is a ridiculously stupid and idiotic approach from a server architecture perspective.
This isn't about the merits or lack thereof of binary logging, or the merits of whatever else systemd brought to the party. This is about needing tweezers, and being given a 500 function swiss army knife, where the other 499 functions get in the way of it being used as a very good tweezer.
Systemd is trying to be my default OS via the init system backdoor. I'll choose my own OS, thanks.
When a service stops my first thought will be check what ${init} says rather than a myriad of different inconsistent logs and badly written shell scripts say.
Then I'll check those logs if required.
Regarding DNS, DHCP et al, yes you have a point. Managing restarts on fail is a logical extension of init however.
Different services have different failure modes with nuances that can never be generically captured by whatever means you chose to launch the service, in any kind of meaningful way. When a Database service stops serving data, my first though isn't "Lets see what the init system thinks", my first thought is "Lets see what I can find in various Database service logfiles" which will, 99.9% of the time, be something specific to the database service.
Inits' job in my view is "start this, and get out of the way". "Start this", and do logging, and do DNS/DHCP/manage-daemons/manage-restarts-on-fail/manage-the-fs/here-is-a-kitchen-sink/do-you-want-fries-with-that/oh-yes-and-here-is-NTP isn't what I am personally looking for in an init system, and - frankly - is a ridiculously stupid and idiotic approach from a server architecture perspective.
This isn't about the merits or lack thereof of binary logging, or the merits of whatever else systemd brought to the party. This is about needing tweezers, and being given a 500 function swiss army knife, where the other 499 functions get in the way of it being used as a very good tweezer.
Systemd is trying to be my default OS via the init system backdoor. I'll choose my own OS, thanks.