On 25/09/2015 17:29, Simon Hobson wrote:
Windows and MacOS both prioritise those tasks needed to get a desktop picture (or login prompt) on the screen - as that gives the illusion of fast boot time.
Oh, yes, definitely. (My client machine runs Windows, and I experience that every day.) It does not mean the dependencies are broken, though: if you can actually display a desktop early on in the initialization process, without stuff breaking, why not do so? It's only cheating if you pretend the initialization is over at this point. Of course, vendors are dishonest and incite the consumer to think the system is ready when the desktop is there, but technically speaking, unless something fails when you try to launch a program from the desktop, it's not dependency mismanagement.
it's not worth trying to do anything until all the background stuff is at least well past it's peak !
Yes, it would be more honest to have a small console in the corner of the desktop that displays everything the system is doing, and users would know to avoid launching heavy programs until the console has stopped scrolling. I'm just afraid that with Windows, the console would *never* stop scrolling. XD
That all hinges around what is meant by "start service A". If "start service" means nothing more than "kick off a process that'll run it" then you are completely correct. On the other hand, if "start service" actually means a process which is only deemed to be complete when it's running and ready to go to work then that's a different matter.
That is the point of readiness notification. Traditional rc systems consider that the service is ready when the process that has launched it dies. This is correct for oneshot services (barring a few exceptions). This is not the case for longrun services, unless the daemon can notify its readiness and the launching script takes advantage of that; but few sysv-rc - or OpenRC - scripts actually bother doing this, so their dependency management is actually incorrect. systemd supports readiness notification, in its own over-engineered way, but doesn't even get it right: see http://ewontfix.com/15/ s6-rc uses the hooks provided by s6 to correctly handle readiness notification.
Of course, regardless of what system or definitions you use - if a service then dies then you have a problem. IMO, "it might die at some indeterminate time" isn't an excuse for not trying to get the "start stuff up" part right.
Apparently Rainer disagrees with that, and seems to think that since you can't get a 100% reliable system, it's useless to get the common case working as smoothly as possible. I've stopped trying to convince him.
Taking the example of syslog - if it dies (regardless of when, whether it's seconds or days after system start) then you are going to lose logging. You can try and manage that (spot the problem and deal with it automatically), but short of predicting the failure in advance, there will always be a window during which logging can be lost.
No, you don't have to lose logs if you're maintaining the logging file descriptor open and your new logger instance can actually reuse it. In that case, logs simply accumulate in the kernel buffer (blocking the client if the buffer fills up), until the logger restarts and can read it. I call this "fd-holding", and it is precisely the only thing of value that systemd's "socket activation" brings. On that point, systemd actually does something better than traditional rc systems. s6-rc, and even just s6, also performs fd-holding for loggers. The system creates a pipe from a service to its logger and maintains it open, so you never lose logs either. You get the useful feature, but not the surrounding socket activation crap. -- Laurent _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng