:: Re: [DNG] Stop the madness!
Inizio della pagina
Delete this message
Reply to this message
Autore: Alessandro Selli
Data:  
To: dng
Oggetto: Re: [DNG] Stop the madness!
On 20/10/18 at 03:55, Steve Litt wrote:

[...]

> Stop the madness!



  👍


[...]

> http://smarden.org/runit/runscripts.htm



  This link is http://smarden.org/runit/runscripts.html actually.


> =======================================================
> #!/bin/sh
> if ping -4 -c1 8.8.8.8 > /dev/null; then
>         (/etc/unbound/primecache.sh &) 
>         exec unbound -dp
> else
>         sleep 1
> fi
> =======================================================



  I am one of those who scoffes when he sees a ping to some Internet
site to test the availability of network connectivity.

  There are dozens of ways this ping could fail beyond being the
networking interface not setup correctly, among the possibilities: the
site being off-line, some router between your box and the specific site
malfunctioning, some firewall filtering ICMP echo-* packets, excessive
lag that makes the pings timeout.  It's also a time-consuming way to
test for connectivity.  Besides, I don't want to let Google know when I
switch my box on and how often do I reconfigure my networking.

  Pinging the default gateway is better:

GW=$(ip route list | sed -rn 's/^default via ([0-9a-f:.]+) .*/\1/p')

ping -c 1 "$GW"


  You could also use ip route list | awk '($1 == "default") {print $3}',
but I figured out awk is considerably slower than sed, 40% slower in
this case.


  Still, this probe too could fail, because if the gateway is some box
outside your control (ie is some apparatus your ISP is in control of) it
too could be firewalled or temporarily off-line (some ISP take a handful
of seconds before you can actually use your default gateway to navigate
the Internet).

  In my opinion when one tests for Internet connectivity one should only
test for some interface being ON and a default gateway being configured
and stop there.  If these two conditions are met, any further issue goes
beyond interface configuration and must be investigated separately,
leaving all your local services go ahead starting and configuring
themselves like they should when your local interface goes up successfully.


  Alessandro



--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE