capercally.bleery670@??? said on Thu, 9 Mar 2023 08:46:28 -0800


>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?

As far as "urban myth", that's an emotional factoid, not a
technological one. I've deleted from my reply everything before your
question because the thread was getting more and more unhelpful.

Your question about the difference between "ready" and "started" is an
important one. The old custom of daemon authors writing daemons that
background themselves when they consider themselves "ready" relies on
the daemon's opinion of its readiness. So does this new and grossly
complex systemd daemon reporting.

Personally, I don't want to take the daemon's word for it. I want proof
of readiness. So, if I need Internet networking before starting
mydaemon, I'd do the following runit run script:

=================================
#!/bin/sh
if ping -c1 8.8.8.8 > /dev/null; then
exec mydaemon
fi
sleep 1
=================================

So if the ping succeeds, meaning you have network connectivity, then
this shellscript's process is replaced by mydaemon. If the ping fails,
meaning compromised network connectivity, at least 1 second elapses
before runit tries again to run mydaemon. But because runit is starting
other daemons during this second, very little time is actually lost.


=================================
#!/bin/sh
if ping -c1 8.8.8.8 > /dev/null; then
exec mydaemon
fi
sleep 1
=================================


>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.


=================================
#!/bin/sh
if dig knowngoodurl.com | grep 'ANSWER SECTION:' > /dev/null; then
exec mydaemon
fi
write_to_log "${timestamp} DNS failure prevents startup of mydaemon"
sleep 1
=================================

With runit I think write_to_log would simply be an echo statement, but
I'm not sure.


>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.

It wouldn't make boot impossibly slow on a parallel startup system,
which I think OpenRC is or can be set to be. Runit and s6 are both
parallel startup. Just incorporate the 1 second pause on failure to
prevent tight loops.

Sysvinit and Epoch don't parallel start, so on these two you're right,
they could slow down boot a lot. This being said, Linux had 10 years
initting with pure sysvinit, and taking dependent daemon's word for
readiness or just inserting strategic sleeps didn't bring systemd to
their knees.

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times
http://www.troubleshooters.com/bookstore/thrive.htm