2

I'm running a Raspberry Pi Model 2B with Raspbian Stretch (Debian).

I have a UI-application (chromium-browser, started via /home/pi/.config/lxsession/LXDE-pi/autostart) and a script started via cron, both of which depend on the actual current time being set when they start (or I'd have to put some ugly hacks in the code to deal with it).

The startup time lags several hours behind, until at some point the time gets synced over WLAN.

I was thinking that maybe I could somehow delay the execution of autostart and cron, until NTP had the chance to sync up.

How would I do that? Or can I start both in some other way?

Improve this question
2

This was covered over on the Raspberry Pi SE site in this Q&A titled: How to force NTPD to update date/time after boot?.

Method #1

This approach looks to be the newer preferred method:

$ timedatectl
      Local time: Thu 2018-07-26 16:10:31 EDT
  Universal time: Thu 2018-07-26 20:10:31 UTC
        RTC time: n/a
       Time zone: America/New_York (EDT, -0400)
 Network time on: no
NTP synchronized: yes
 RTC in local TZ: no

If it's not enabled:

$ timedatectl set-ntp True
root@pi-hole:~ # timedatectl
      Local time: Thu 2018-07-26 16:11:45 EDT
  Universal time: Thu 2018-07-26 20:11:45 UTC
        RTC time: n/a
       Time zone: America/New_York (EDT, -0400)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Method #2

This approach looks to be the older method for doing this:

$ sudo apt-get install ntpdate

According to that question:

ntpdate will run when an ethernet interface is brought up, and set the time from an ntp server (see /etc/default/ntpdate).

If ntpd is running, ntpdate will do nothing, however ntpdate will run prior to ntpd at bootup - so this should work out to set the time at bootup as long as there's an ethernet connection.

Incidentally my version of Raspian did not have this enabled either:

$ more /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

My conclusions on methods 1 & 2

Further researching these solutions, I saw no indications of where this would in fact ever run, so the comments from the other AU Q&A's is a little perplexing to me. If it were connected to the NIC's up state, I'd expect to see something like this:

$ cat /etc/network/interfaces
auto eth0
    iface eth0 inet dhcp
    post-up /usr/local/sbin/update-time.sh

# REF: https://askubuntu.com/a/708832/17531

Method #3

Given the above state of affairs I ended up implementing NTP syncing like this on my Raspberry Pi (Raspian) as well.

In the end I merely added this to my /etc/rc.local:

$ cat /etc/rc.local
logger "Beginning force syncing NTP..."
service ntp stop
ntpd -gq
service ntp start
logger "Finished force syncing NTP..."

Which results in this in /var/log/syslog:

Aug  5 09:10:20 pi-hole ntp[526]: Starting NTP server: ntpd.
Aug  5 09:10:20 pi-hole ntpd[555]: proto: precision = 1.458 usec (-19)
Aug  5 09:10:20 pi-hole ntpd[555]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:20 pi-hole ntpd[555]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:21 pi-hole ntpd[555]: ntpd exiting on signal 15 (Terminated)
Aug  5 09:10:21 pi-hole ntp[661]: Stopping NTP server: ntpd.
Aug  5 09:10:21 pi-hole ntpd[674]: ntpd 4.2.8p10@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1): Starting
Aug  5 09:10:21 pi-hole ntpd[674]: Command line: ntpd -gq
Aug  5 09:10:21 pi-hole ntpd[674]: proto: precision = 0.625 usec (-21)
Aug  5 09:10:21 pi-hole ntpd[674]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:21 pi-hole ntpd[674]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:34 pi-hole ntpd[674]: Soliciting pool server 198.98.57.16
Aug  5 09:10:35 pi-hole ntpd[674]: Soliciting pool server 74.82.59.149
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 23.131.160.7
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 52.37.26.163
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 204.2.134.163
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 96.126.100.203
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 199.223.248.101
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 66.228.42.59
Aug  5 09:10:36 pi-hole ntpd[674]: Soliciting pool server 208.75.89.4
Aug  5 09:10:37 pi-hole ntpd[674]: Soliciting pool server 204.2.134.164
Aug  5 09:10:37 pi-hole ntpd[674]: Soliciting pool server 104.236.116.147
Aug  5 09:10:38 pi-hole ntpd[674]: Soliciting pool server 204.9.54.119
Aug  5 09:10:48 pi-hole ntpd[674]: ntpd: time set +6.769186 s
Aug  5 09:10:49 pi-hole ntpd[853]: ntpd 4.2.8p10@1.3728-o Sat Mar 10 18:03:33 UTC 2018 (1): Starting
Aug  5 09:10:49 pi-hole ntpd[853]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 111:114
Aug  5 09:10:49 pi-hole ntp[844]: Starting NTP server: ntpd.
Aug  5 09:10:49 pi-hole ntpd[856]: proto: precision = 0.625 usec (-21)
Aug  5 09:10:49 pi-hole ntpd[856]: Listen and drop on 0 v6wildcard [::]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 2 lo 127.0.0.1:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 3 eth0 192.168.1.85:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 4 lo [::1]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listen normally on 5 eth0 [fe80::f5ea:7663:4ec:784d%2]:123
Aug  5 09:10:49 pi-hole ntpd[856]: Listening on routing socket on fd #22 for interface updates
Aug  5 09:10:49 pi-hole root: Finished force syncing NTP...

Why would I need rc.local?

Things I noticed while looking into this revolved around the installation of other NTP services such as chrony or ntpd. Having these on a system would negate systemd's timedatectl facilities, mainly through this file:

$ cat /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

Resulting in this:

$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Sun 2018-08-05 10:05:53 EDT; 1s ago
           └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
     Docs: man:systemd-timesyncd.service(8)

Removing everything so that we only rely on systemd's timesyncd facility:

$ cat /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf |awk -F'=!' '/Condition/ {print $2}' | xargs ls
ls: cannot access '/usr/sbin/ntpd': No such file or directory
ls: cannot access '/usr/sbin/openntpd': No such file or directory
ls: cannot access '/usr/sbin/chronyd': No such file or directory
ls: cannot access '/usr/sbin/VBoxService': No such file or directory

Now allows it to run:

$ systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Sun 2018-08-05 10:14:44 EDT; 5s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 3714 (systemd-timesyn)
   Status: "Synchronized to time server 108.59.2.24:123 (0.debian.pool.ntp.org)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─3714 /lib/systemd/systemd-timesyncd

Aug 05 10:14:44 pi-hole systemd[1]: Starting Network Time Synchronization...
Aug 05 10:14:44 pi-hole systemd[1]: Started Network Time Synchronization.
Aug 05 10:14:45 pi-hole systemd-timesyncd[3714]: Synchronized to time server 108.59.2.24:123 (0.debian.pool.ntp.org).

On Raspian (assuming Ubuntu & Debian would be like this as well) the comments in the config file for timesyncd.conf appear to indicate that there's already NTP servers hardcoded in:

$ cat /etc/systemd/timesyncd.conf
...
...
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org

Forcing a sync

It doesn't appear that there's any method to force a sync directly. Restarting the systemd-timesyncd service does in fact trigger a resync though:

$ systemctl restart systemd-timesyncd

You can see this in the logs:

$ journalctl -u systemd-timesyncd
-- Logs begin at Thu 2016-11-03 13:16:42 EDT, end at Sun 2018-08-05 10:44:37 EDT. --
Aug 05 10:14:44 pi-hole systemd[1]: Starting Network Time Synchronization...
Aug 05 10:14:44 pi-hole systemd[1]: Started Network Time Synchronization.
Aug 05 10:14:45 pi-hole systemd-timesyncd[3714]: Synchronized to time server 108.59.2.24:123 (0.debian.pool.ntp.org).
Aug 05 10:44:37 pi-hole systemd[1]: Stopping Network Time Synchronization...
Aug 05 10:44:37 pi-hole systemd[1]: Stopped Network Time Synchronization.
Aug 05 10:44:37 pi-hole systemd[1]: Starting Network Time Synchronization...
Aug 05 10:44:37 pi-hole systemd[1]: Started Network Time Synchronization.
Aug 05 10:44:37 pi-hole systemd-timesyncd[4157]: Synchronized to time server 208.75.88.4:123 (0.debian.pool.ntp.org).

The last line is from my restart. Beyond a restart, the version of systemd-timesyncd on this particular version of Raspian does not include this patch - timesync: make poll interval configurable #7268, so you cannot control syncing beyond restarting.

In later versions of systemd-timesyncd you can with this option:

   PollIntervalMinSec=, PollIntervalMaxSec=

   The minimum and maximum poll intervals for NTP messages. Each setting takes a time 
   value (in seconds). PollIntervalMinSec= must not be smaller than 16 seconds. 
   PollIntervalMaxSec= must be larger than PollIntervalMinSec=. PollIntervalMinSec= 
   defaults to 32 seconds, and PollIntervalMaxSec= defaults to 2048 seconds.

References

Improve this answer
7
  • Thanks for your answer. The NTP sync is enabled, my problem is, that it happens only some time after boot. I can't have my programs start before time is properly set. So I need to delay that start. – user3768649 Jul 30 '18 at 14:41
  • @user3768649 - then I'd suggest using ntpdate as I mentioned in the 2nd method. This will perform a sync when the network NIC is brought up. – slm♦ Jul 31 '18 at 1:33
  • Installing ntpdate had no effect for me. The time was still off when the programs started. Probably because the startup doesn't wait until the time is set. – user3768649 Aug 5 '18 at 10:27
  • @user3768649 - further research, I'm seeing the same issue you are when looking more closely at it. I don't see NTP running "automagically" and so have added a 3rd method which does it more forcibly. – slm♦ Aug 5 '18 at 13:56
  • 1
    ntpd -gq appears just like in your log above. Using systemd services for my applications was not successful yet, I was trying Requires= and After=time-sync.target, which should run after systemd-timesyncd. Problem is I think, that the target is met after systemd-timesyncd started, not after it actually synced the time, so my own services again start too early. – user3768649 Aug 9 '18 at 19:43
0

So what I ended up doing is implementing some rudimentary time jump recognition in the script and the application.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.