Florian Zieboll <f.zieboll@???> wrote:

> Seriously, what else besides dependencies on other daemons that have to
> be running and some testing for the existence of certain (everything is)
> files would be necessary to pass to a parser script, which could be
> packaged with the respective init system?

Are we in danger of removing one of the great benefits of the shell scripts used by sysvinit - the ability to code pretty well anything that's needed. I realise that this also means the scripts can tend to "sprawl", but it gives great flexibility - including for local modifications.

So for example, a database init script can go further than just checking that the daemon has started, it can run specific queries against the database to determine that it's actually ready to serve queries before returning "started". I believe MySQL does this - hence a sprawling script.

For local modifications, it may be desirable to check that a service is running on a remote host before starting. For example, I have a small mail server cluster that uses a single policy daemon running on a backend machine - although I haven't done it, it would be fairly easy on the shell script to wait for that service to be available before starting Postfix.

While both of these could be handled with a set of "before starting", "after starting", etc type hooks to call external scripts - IMO we're then into an even worse situation where you have a config file feeding into the block box of hidden logic AND have one or more scripts containing exactly what people are criticising SysV for.