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