Isaac Dunham <ibid...@gmail.com> writes: > On Thu, Sep 24, 2015 at 02:31:40PM +0100, Rainer Weikusat wrote: >> Laurent Bercot <ska-de...@skarnet.org> 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng