❦ 24 octobre 2014 23:04 +0100, Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> :
>> All of them are relying on the fact that the monitored process won't
>> fork. They are therefore not able to handle readiness and
>> dependencies.
>
> Also untrue. Handling dependencies has nothing to do with forking,
[...]
Yes it has. Many daemons fork when they are ready. Because some of them
fail to behave correctly don't mean that you can just give up on that
aspect like most of the inits you cited do. systemd is compatible with
this behaviour and also propose other ways (socket activation or its own
readiness protocol). It tries to solve the problem and it is succesful
in doing so. We see more and more services being socket-activated.
> And as I said, dependencies have nothing to do with forking.
> Dependencies are a matter of having some way of specifying
> dependencies in service configurations, and topologically sorting the
> low-level start/stop tasks. Felix von Leitner's minit was doing
> dependencies back in 2000.
Without being able that a service is ready, dependencies are not
reliable. A database will never be ready just after start and any
service started just after the database will rely on retries and timeout
to start or just fail miserably.
--
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)
Attachment:
signature.asc
Description: PGP signature