LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-22-2020, 12:53 AM   #1
eduardr
Member
 
Registered: Sep 2011
Distribution: Slackware64 14.2+ (-current)
Posts: 81

Rep: Reputation: Disabled
RPi4 (Sarpi) - rc.local ntpdate "hack" fails to update date/time


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.
 
Old 03-22-2020, 03:07 AM   #2
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 656

Rep: Reputation: 381Reputation: 381Reputation: 381Reputation: 381
Quote:
Originally Posted by eduardr View Post
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.
 
2 members found this post helpful.
Old 03-22-2020, 09:18 AM   #3
interndan
Member
 
Registered: Aug 2004
Location: near Marion, Ill
Distribution: Slackware 14.2 64bit on Desktop Slackwarearm on Raspberry PI v1b
Posts: 364

Rep: Reputation: 35
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.
 
4 members found this post helpful.
Old 03-22-2020, 07:20 PM   #4
eduardr
Member
 
Registered: Sep 2011
Distribution: Slackware64 14.2+ (-current)
Posts: 81

Original Poster
Rep: Reputation: Disabled
Talking Success using just rc.ntpd enabled at boot

@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.
 
2 members found this post helpful.
Old 03-29-2020, 11:08 AM   #5
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 250

Rep: Reputation: 150Reputation: 150
Quote:
Originally Posted by Exaga View Post
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

Last edited by TheTKS; 03-29-2020 at 11:10 AM. Reason: Add using NetworkManager
 
Old 03-29-2020, 03:15 PM   #6
eduardr
Member
 
Registered: Sep 2011
Distribution: Slackware64 14.2+ (-current)
Posts: 81

Original Poster
Rep: Reputation: Disabled
rc.ntpd works better for me

Quote:
Originally Posted by TheTKS View Post
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.
 
1 members found this post helpful.
Old 03-29-2020, 05:33 PM   #7
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 656

Rep: Reputation: 381Reputation: 381Reputation: 381Reputation: 381
Quote:
Originally Posted by TheTKS View Post
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 View Post
@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.

Last edited by Exaga; 03-30-2020 at 11:00 AM. Reason: added code
 
2 members found this post helpful.
Old 03-29-2020, 08:27 PM   #8
TheTKS
Member
 
Registered: Sep 2017
Location: The deep south... of Canada
Distribution: Slackware, Xubuntu, OpenBSD, elementary, Raspberry Pi OS, Puppy, TinyCore
Posts: 250

Rep: Reputation: 150Reputation: 150
Quote:
Originally Posted by Exaga View Post
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 View Post
@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

Last edited by TheTKS; 03-29-2020 at 08:35 PM.
 
Old 03-31-2020, 07:56 PM   #9
gus3
Member
 
Registered: Jun 2014
Distribution: Slackware (x86 and ARM)
Posts: 432

Rep: Reputation: Disabled
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.)
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
RPi4 (Sarpi) - Installs OK from USB stick, but not from pre-mounted dir on /floppy eduardr Slackware - ARM 2 03-22-2020 02:59 AM
SARPI (fatdog) on RPi4 - no HDMI video [SOLVED] arfon Slackware - ARM 4 03-17-2020 01:47 AM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM
ntpdate XXX works ; ntpdate -q XXX don't works - ntpd stays on local oudoubah Linux - Software 5 12-12-2011 07:28 AM
ntpdate/ntpd time is in UTC instead of local time? m4rtin Linux - Software 7 05-06-2011 07:57 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 10:01 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration