capercally.bleery670@??? writes:
> 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"?

I wrote that the idea that a server process will first complete its
initialisation to the point of being ready to serve clients and then
fork itself into the background was urban myth and gave three examples
of real-world server not behaving in this way.

I also wrote that "daemon readiness" wouldn't be a well-defined
concept. That's the case because this information is always necessarily
historical: A daemon being ready to serve at some time X doesn't mean
it'll still be ready at a time X + N, N > 0.

Regardless of both, init scripts do declare dependencies on other init
scripts. For ordinary runlevel server start scripts, that's essentially
nonsense (and Debian has defaulted to starting all servers with priority
20 since at least 1998) but not so for the system initialization scripts
called via /etc/rcS.s.