:: Re: [DNG] [announce] s6-rc, a s6-ba…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Isaac Dunham <ibid.ag@???> writes:
> On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote:
>> Laurent Bercot <ska-devel@???> writes:
>>
>> [...]
>>
>> > It manages dependencies between services, no matter whether they are
>> > oneshots or longruns; it can intertwine oneshot starts and longrun
>> > starts, or oneshot stops and longrun stops. When changing the machine
>> > state, it always ensures the consistency of the dependency graph.
>>
>> I'd still very much like to see an actual example which really needs
>> these depenencies which isn't either bogus or a workaround for a bug in
>> the software being managed.
>
> Well, let's see:
>
> * cups should be started after avahi if you want zeroconf network printers
> accessible by name


[more of this]

If a certain server doesn't handle "dynamic network configuration
changes" as it ought to, "starting it such that it hopefully won't have
to" is a sensible workaround.

> * anything that uses the syslog should start after the syslog.


That's the same misunderstanding already shown elsewhere: Starting
syslog at time X and starting syslog-user at time Y, Y > X, Y - X being
'very small', does not guarantee syslog will already be available at
time Y and neither that it will still be available provided it became
available in the time interval between X and Y. And there is, of course,
another time Z involved here, Z > Y, Z - Y unknown, which is the time
when the services started at time Y will actually log the first
message. Unless syslog is available at that time, the message will
likely be lost. But "it was started earlier than the program trying to
log the message" does not guarantee that (and neither does "it was
started later" preclude it).

NB: I'm going to break this off here because I'm not interested in
trying to convince anyone of anything. I'm maintaining a certain,
proprietary system which works fine without performing a topological
sort of "actions to be performed" to determine a partial ordering for
them based on declared dependencies on startup.