Re: Is missing SysV-init support a bug?

[Gerrit Pape <pape@smarden.org>]

On Mon, Aug 29, 2016 at 09:47:53PM +0200, Simon Richter wrote:
> On 28.08.2016 22:11, Bart Schouten wrote:
> > That "very serious race condition" is nothing more than one daemon
> > having to wait for the other while starting up. THAT'S IT. Oh and
> > knowing when something has died so you can restart it or something.
> 
> That is also something the init system can not really fix, just paper over.
> 
> Any daemon that is dependent on another to work needs to be able to
> handle the case where the other process is restarted, or fails for some
> reason, and provide error recovery in this case. Declaring a dependency
> in a systemd unit file is no better in that regard than simply ordering
> daemons by priority, and ideally the daemon needs to be resilient enough
> to work even if the other daemon is started with no synchronisation or
> if timed jobs are simply not run.
> 
> I'd also postulate that these error cases are not properly tested in
> most daemons we have. Every service can always fail due to transient
> errors, and this needs to be communicated up the stack. There is a
> reason why SMTP daemons will first write a mail to disk, flush the
> caches, and only then acknowledge receipt.

To me too this readiness IPC ideas and implementations look
over-engineered.

A good convention for service programs would be to functionally test for
services it needs very early on startup, and fail if dependencies are
not available.  The service supervisor (any modern init scheme seems to
now support this) relaunches eventually, until all dependencies are
fulfilled.  Consequently, if while running one of the needed services
fails for some reason, fail also.  Supervisors are going to bring things
up again.  That's how runit does things.

If the initialization of some (bloat) service program really is that
expensive before it can functionally check for dependencies, it could
implement the wait-and-retry on its own.

Good thing is that this convention applies to the service program that
actually is causing the issue (multiple, expensive startups) and can be
fixed there, while readiness IPC requires the dependencies to "fix"
things.

Regards, Gerrit.