Boot order and dependencies - getting PPP to wait

[gpw928]

Oh, wait. I don't see any "shell" command.

The ppp(8) manual saysAll external commands (executed via the "shell" or "!bg" commands) are executed.... So "shell" is for foreground and "!bg" is for background commands. You may want to wait for some things, and not for others (so different scripts run by "shell" and, subsequently, "!bg"). Choose wisely.

So... Just move pfctl, ntpdate, and named out of the rc hierarchy and into ppp.linkup.cmd and in ppp.linkup

CenturyLink:
    !bg /etc/ppp.linkup.cmd

Yes, and no. You still want rc scripts to work by themselves when you choose to restart an individual service. And one of the places where you restart those services (with service xxx restart) is in the script that gets invoked by the "link-up" asynchronous event. You manage this on a case by case basis. Make sure that the rc script does not compromise the system if the Internet is not up, and does what you want when the Internet is up.

 

[ralphbsz]

• On substantial networks, I use three internal NTP time servers on physical Unix hosts (with clock chips) running as peers at strata 10, 12, and 14 -- so I don't have to have the Internet time servers (typically at superior strata 0, 1, 2, ...) to keep time, but will always use them if available.

Agree. My setup is similar but much simpler: I have ONE server machine on my home network (which runs FreeBSD). If that machine is down, all networking is down: no routing, no DNS, no DHCP addresses, the WiFi is unreachable, and so on. That machine has a half-decent hardware clock (the typical PC motherboard one), good enough to get through a few hours or days without outside NTP. Once the network to the outside world comes up, it synchronizes itself to real NTP servers.

BUT: One thing I found is that it is crazy to run a Unix machine without a hardware clock. That was the situation on my Raspberry Pi machines for a while. You end with files have modifications times of 1970, or log entries in places like /var/log/messages that jump back and forth by decades, and break any form of log analysis. So what I did is: (a) Configure SystemD (the much maligned software) so if nothing else is available, it uses a half-decent estimate of current time from date stamps is finds on disks, and (b) add inexpensive 5-pin real-time clock chips (attach right to the GPIO) wherever possible. With this, the problems of insane times getting persisted have gone away.