On Wed, Mar 08, 2023 at 03:47:31PM +0000, Rainer Weikusat via Dng wrote:
> capercally.bleery670@??? writes:
> > On Tue, Mar 07, 2023 at 03:22:53PM +0000, Rainer Weikusat via Dng wrote:
> >> > Traditionally, this type of daemon would remain in foreground until it
> >> > was functional, and then doublefork itself, at which time sysvinit
> >> > would run the next daemon.
> >>
> >> That's an urban myth. There is no such convention and "daemon readiness"
> >> isn't a well-defined concept. Current implementations of SysV-RC start
> >> jobs in parallell (and have for some time).
> >
> > The traditional symlinks and sequence numbers are still there, though.
> > What purpose do they serve, then? At what point does rc proceed from
> > handling /etc/rc2.d/S02unbound to /etc/rc2.d/S03cron ? (or is there such
> > a distinct point at all?)
>
> This depends on how the system is configured. By default, startpar is
> used to run scripts which are independent of each other (as determined by
> reading the dependency files generated by insserv from script LSB
> headers) in parallell. If the file /etc/init.d/.legacy-bootordering
> exists or if concurrency=none was passed on the kernel command line, the
> scripts will be started one-by-one in the order of their sequence numbers
> (ie in the order the names will be returned when expanding the shell
> patterns K* and S*).

Ok Ok, but how do you reconcile the concept of "independent of each other"
with "daemon readiness is an urban myth"? Surely if they are *not*
independent, ie. one depends on another, the dependence is precisely on
the other being "ready" and not just having been started?

My example above is imperfect because cron rarely needs to query DNS, but
suppose otherwise for the sake of argument; let's say cron needs to mail
the output of jobs non-locally, so needs to look up the destination MX.
Clearly that won't work until unbound actually starts answering queries.

In theory, rc scripts can be written so they actually check whatever
"ready" means in each particular case, ie. in our example the unbound
script could be written to keep sending a DNS query until it is answered.
In practice this seems to almost never be done, probably because it would
make boot impossibly slow.

--
Ian