[SOLVED] RPi4 (Sarpi) - rc.local ntpdate "hack" fails to update date/time

eduardr · 03-22-2020, 12:53 AM

Currently am without an RTC module (waiting to receive a RasClock RTC module), so my new RPi4 Sarpi setup is using the ntpdate "hack" which runs ntpdate via rc.local.

I noticed that the date/time does not get set after boot (stays at default 1969 value), but there was no message or warning. So I changed the line in /etc/rc.d/rc.local -

from:

Code:

ntpdate 0.pool.ntp.org > /dev/null 2>&1

to:

Code:

ntpdate 0.pool.ntp.org

In order to see whatever warnings/errors are generated.

I see this when I boot:

Code:

Exiting, name server cannot be used: Temporary failure in name resolution (-3) 3 ...

But when I run rc.local manually after boot, then it updates the time properly.

My system is set to use Network Manager to configure networking, using the WiFi connection via DHCP/auto. After boot, /etc/resolv.conf contains the expected entries, and name resolution works fine.

Blind guess as to what might be going on:
* Maybe the WiFi connection bring-up/DHCP is still in progress when rc.local runs during boot, and the name servers are not yet configured in /etc/resolv.conf

In case this possibility might bite others, maybe would make sense to remove the > /dev/null 2>&1 piece from rc.local in sarpi hacks? This way at least if the ntpdate fails the user would get to see the error.

Once I receive my RTC module I will avoid having to figure out what's really going on.

Exaga · 03-22-2020, 03:07 AM

Quote:

Originally Posted by eduardr

Currently am without an RTC module (waiting to receive a RasClock RTC module), so my new RPi4 Sarpi setup is using the ntpdate "hack" which runs ntpdate via rc.local.

I noticed that the date/time does not get set after boot (stays at default 1969 value), but there was no message or warning.

Blind guess as to what might be going on:
* Maybe the WiFi connection bring-up/DHCP is still in progress when rc.local runs during boot, and the name servers are not yet configured in /etc/resolv.conf

Try:

Code:

sleep 60 ; ntpdate 0.pool.ntp.org > /dev/null 2>&1

If you don't have a valid connection to the Internet when the 'ntpdate' command executes then this will be why the address fails to resolve. Adding a sleep timer delays the execution of the command until (hopefully) there is Internet connectivity.

interndan · 03-22-2020, 09:18 AM

I don't know if this will help as I don't use network manager, but in wicd I always set a post command to run ntpdate. That way the time is always (re)set after the network connection is established.

eduardr · 03-22-2020, 07:20 PM

@Exaga thanks! Your suggested sleep approach definitely worked well and I did further investigation to figure out the minimum sleep time that would work for me when using NetworkManager (documented below). One issue I ran into with the rc.local approach is that it's not possible to use /etc/rc.d/rc.ntpd (i.e. chmod a+x /etc/rc.d/rc.ntpd). When ntpd is running, attempting to launch ntpdate from rc.local fails with ntpdate[960]: the NTP socket is in use, exiting

@interndan thanks! Based on your suggestion I looked into NetworkManager and learned about script(s) I can add to /etc/NetworkManager/dispatcher.d/ to run commands based on the state change of network interfaces (documented below).

After pursuing both of these approaches with success, it turned out that neither are necessary: simply setting rc.ntpd to start at boot (i.e. chmod a+x /etc/rc.d/rc.ntpd) is enough, as the ntpd daemon itself does a full date/time update when it starts up. I seem to remember some time back that ntpd would not update the date/time if the difference between system time and real time was too great, but currently it does do a proper update to the real date/time when it launches.

Below, documenting the first two approaches even though they're not necessary when using rc.ntpd at boot.

First approach: rc.local

In order to figure out why ntpdate was failing and how much sleep would be needed, I added the following to rc.local:

Code:

cat /etc/resolv.conf > /tmp/resolv_at_boot.txt
for i in 00 01 02 03 04 05 06 07 08 09 10; do
  ifconfig > /tmp/ifconfig_at_boot_sleep${i}.txt
  sleep 1
done
ntpdate 0.pool.ntp.org

From this I learned that resolv.conf was NOT the issue. It was already properly populated when rc.local runs. The issue was ifconfig showed no IP address for the wifi interface until some number of seconds of sleep elapsed. Most times I'm seeing a minimum of 7 seconds required, but just now I rebooted and saw that it took significantly longer for wifi to establish an IP address. So with this approach maybe 20-40 seconds would be a safe sleep amount "most of the time".

Difference in ifconfig output for the wifi was as follows -

Before X seconds of sleep:

Code:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 abcdefghijkl  prefixlen 64  scopeid 0x20<link>
        ether 12:34:56:78:90  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2  bytes 228 (228.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

After X seconds of sleep:

Code:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.151  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 abcdefghijkl  prefixlen 64  scopeid 0x20<link>
        ether 12:34:56:78:90  txqueuelen 1000  (Ethernet)
        RX packets 4  bytes 609 (609.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 821 (821.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Second approach: /etc/NetworkManager/dispatcher.d/

Thanks to these pages:

Linux : NetworkManager's /etc/NetworkManager/dispatcher.d/ test script does not work. code included
https://stackoverflow.com/questions/16848021

Gnome - NetworkManager
https://developer.gnome.org/NetworkM...rkManager.html

I created the following script: /etc/NetworkManager/dispatcher.d/ntpdate

Code:

#!/bin/sh -e
# Script to run ntpdate when an interface is up
#
# See NetworkManager(8) for further documentation of the dispatcher events.

# Notes: 
# o This script receives a NetworkManager event string as parameter $2

case "$2" in
    up)
	# Run ntpdate
        logger -s "NetworkManager interface up event - running ntpdate"
        ntpdate 0.pool.ntp.org > /dev/null 2>&1
        exit 0
    ;;
    *)
        # Do nothing
	exit 0
    ;;
esac

This script is run automatically by NetworkManager whenever anything changes with the network interfaces. If the script sees an event of type "up", it runs ntpdate.

TheTKS · 03-29-2020, 11:08 AM

Quote:

Originally Posted by Exaga

Try:

Code:

sleep 60 ; ntpdate 0.pool.ntp.org > /dev/null 2>&1

If you don't have a valid connection to the Internet when the 'ntpdate' command executes then this will be why the address fails to resolve. Adding a sleep timer delays the execution of the command until (hopefully) there is Internet connectivity.

Thanks, Exaga. I had the same problem so was running ntpdate manually.

Since adding the sleep timer to /etc/rd.c/rc.local, the time has been updating on its own.

I was able to shorten the sleep timer to 5. It might be worth trying times shorter than 60 if you're impatient. :-)

I am using NetworkManager.

TKS

eduardr · 03-29-2020, 03:15 PM

Quote:

Originally Posted by TheTKS

Since adding the sleep timer to /etc/rd.c/rc.local, the time has been updating on its own.

I was able to shorten the sleep timer to 5. It might be worth trying times shorter than 60 if you're impatient. :-)
I am using NetworkManager.

TKS

@TheTKS using rc.local it will only update the date/time a single time, when it boots. If you're running the machine continuously for weeks/months, it will lose/gain more and more time as it goes.

From my testing the following worked better to keep it updated:

1. Remove or comment out ntpdate update from rc.local

2. Edit /etc/ntp.conf to enable something like the following set of servers:

Code:

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst

3. Enable rc.ntpd at boot:

Code:

$ chmod a+x /etc/rc.d/rc.ntpd

4. Start it now:

Code:

$ /etc/rc.d/rc.ntpd start

If you continue using the rc.local approach, 5 seconds of timeout is not "safe" in the sense with WiFi I've seen easily 10 seconds, in one case 20-30 until the interface is up and can be used to update the date/time. Because the amount of time needed is so variable, this was not a reliable solution for me unless you're willing to set it to 30 or maybe even 60, or live with date/time not updating at boot properly "once in a while" randomly.

Exaga · 03-29-2020, 05:33 PM

Quote:

Originally Posted by TheTKS

Thanks, Exaga. I had the same problem so was running ntpdate manually.

Since adding the sleep timer to /etc/rd.c/rc.local, the time has been updating on its own.

The 60 seconds was complete overkill - just to be sure. Glad it helped.

Quote:

Originally Posted by eduardr

@TheTKS using rc.local it will only update the date/time a single time, when it boots. If you're running the machine continuously for weeks/months, it will lose/gain more and more time as it goes.

I've added a simple script to /etc/cron.hourly/ much the same as, and in addition to, running the command in /etc/rc/rc.local at boot time - to keep the date/time accurate.

Code:

~# cat /etc/cron.hourly/synchronux.sh

#!/bin/sh

# Set system date/time and write to hardware clock
/usr/sbin/ntpdate 192.168.1.222 > /dev/null 2>&1 
/sbin/hwclock -w  > /dev/null 2>&1

* The RPis have battery-backed real time clocks installed which is the reason for syncing the system timestamp with hwclock.

TheTKS · 03-29-2020, 08:27 PM

Quote:

Originally Posted by Exaga

I've added a simple script to /etc/cron.hourly/ much the same as, and in addition to, running the command in /etc/rc/rc.local at boot time - to keep the date/time accurate.

Quote:

Originally Posted by eduardr

@TheTKS using rc.local it will only update the date/time a single time, when it boots. If you're running the machine continuously for weeks/months, it will lose/gain more and more time as it goes.

From my testing the following worked better to keep it updated...

If you continue using the rc.local approach, 5 seconds of timeout is not "safe" in the sense with WiFi I've seen easily 10 seconds, in one case 20-30 until the interface is up and can be used to update the date/time.

eduardr, Exaga,

For my RPi weekend hobby usage, on for a few hours at a time, the startup script with sleep timer as Exaga wrote is sufficient.

A 5 sec startup sleep timer might not always be enough, but that's easy enough to adjust or manually update from time to time.

Thanks for the reminder that under extended use, continual time updates would be needed, and for your suggestions how to do that. If I end up doing something that will have the RPi on for weeks or more, then I will have to do something to continually correct the RPI's time. I think I would notice the time being off after awhile and would reset it manually, but it's way better to automate it!

TKS

gus3 · 03-31-2020, 07:56 PM

For setting the time/date at boot, I use the /etc/rc.d/rc.firewall script. The network is up and running, so another (local) time server should suffice, at least to initialize the timestamp.

Code:

#!/bin/sh

# The RPi has no on-board clock. Set the time from firewall immediately.
echo -n "Setting time from main server... "
/usr/sbin/ntpdate -s $LOCAL_NTP_SERVER # change to your server's name/addr
echo "Done. Date is now $(date)"

In my particular case, the firewall is also the local DHCP and NTP server. The outside stuff gets set up first, then the local services are started, taking care to keep them only on 192.168.N.0/24. (For various values of N.)