Systemd-users, just a NTP-tip

I've been running ntpdate & ntp for a long time.

The problem has always been that the ntp-service doesn't start at boot cos the sockets are in use (thanks to ntpdate).
And if you uninstall ntpdate, ntp will fail 'cos the gap from 1970 is to big... And the -g option won't work either...

You could always add a line to rc.local etc if you want but that's a bit messy for my taste. I rather have one solution that works out of the box.

With systemd (which i've only been using for 2 days) you can use "systemd-timesyncd" instead of both ntpdate and ntp(d).

Works great and sets the time at a early stage (no more 1970 in the logs).

Heres how you enable it, you will need to uninstall ntpdate and ntp(d).
https://wiki.archlinux.org/index.php/Systemd-timesyncd

root@pp01:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
   Active: active (running) since Wed 2015-04-01 01:47:48 CEST; 4min 11s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 178 (systemd-timesyn)
   Status: "Using Time Server 94.246.113.188:123 (0.debian.pool.ntp.org)."
   CGroup: /system.slice/systemd-timesyncd.service
           └─178 /lib/systemd/systemd-timesyncd

Jan 01 01:00:17 pp01 systemd-timesyncd[178]: System clock time unset or jumped backwards, restoring from recorded timestamp: Wed 2015-04-01 01:47:48 CEST
Apr 01 01:47:48 pp01 systemd[1]: Started Network Time Synchronization.
Apr 01 01:47:48 pp01 systemd-timesyncd[178]: Using NTP server 94.246.113.188:123 (0.debian.pool.ntp.org).
Apr 01 01:48:43 pp01 systemd-timesyncd[178]: interval/delta/delay/jitter/drift 32s/+54.774s/0.017s/0.000s/+0ppm
Apr 01 01:49:15 pp01 systemd-timesyncd[178]: interval/delta/delay/jitter/drift 64s/-0.004s/0.017s/0.002s/+0ppm
Apr 01 01:50:19 pp01 systemd-timesyncd[178]: interval/delta/delay/jitter/drift 128s/-0.007s/0.016s/0.006s/-26ppm
= KICKASS!!!

/John



Edited 1 time(s). Last edit at 03/31/2015 06:53PM by JohnW.

@John,

I think this is a good hint on running systemd, no doubt.

However, I still don't see ntp and ntpdate have problem at all since I've been running them for a few years. Here is a just rebooted Dockstar log:

root@Dockstar:/localdisk/linux/uboot# logread | grep ntp

Mar 30 02:33:28 Dockstar daemon.notice ntpdate[1087]: step time server 164.67.62.194 offset 1427707973.008862 sec
Mar 30 02:33:42 Dockstar daemon.notice ntpdate[1915]: adjust time server 164.67.62.194 offset 0.000625 sec
Mar 30 02:33:51 Dockstar daemon.notice ntpd[2109]: ntpd 4.2.6p5@1.2349-o Sat Feb  7 11:50:05 UTC 2015 (1)
Mar 30 02:33:51 Dockstar daemon.notice ntpd[2110]: proto: precision = 1.435 usec
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen and drop on 1 v6wildcard :: UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen normally on 2 lo 127.0.0.1 UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen normally on 3 eth0 192.168.0.220 UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen normally on 4 eth0 fe80::210:xx:xx UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listen normally on 5 lo ::1 UDP 123
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: peers refreshed
Mar 30 02:33:51 Dockstar daemon.info ntpd[2110]: Listening on routing socket on fd #22 for interface updates

root@Dockstar:/localdisk/linux/uboot# dmesg -T | head

[Mon Mar 30 02:32:53 2015] Booting Linux on physical CPU 0x0
[Mon Mar 30 02:32:53 2015] Initializing cgroup subsys cpuset
[Mon Mar 30 02:32:53 2015] Initializing cgroup subsys cpu
[Mon Mar 30 02:32:53 2015] Initializing cgroup subsys cpuacct
[Mon Mar 30 02:32:53 2015] Linux version 3.18.5-kirkwood-tld-1 (root@tldDebian) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 PREEMPT Thu Feb 5 17:58:07 PST 2015
[Mon Mar 30 02:32:53 2015] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f
[Mon Mar 30 02:32:53 2015] CPU: VIVT data cache, VIVT instruction cache
[Mon Mar 30 02:32:53 2015] Machine model: Seagate FreeAgent Dockstar
[Mon Mar 30 02:32:53 2015] Memory policy: Data cache writeback
[Mon Mar 30 02:32:53 2015] On node 0 totalpages: 32768

Could it be that there is something about your rootfs that does not like these time services as they supposed to be used in sysvinit?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 03/31/2015 07:19PM by bodhi.

I've had these problems from the beginning - all since last year when i started off with your 3.16 image.
It's that ntp is started to close to ntpdate. I've have never had it working correct.

I can see that your ntpd is starting 9 seconds after ntpdate. At that time ntpdate is probably done and the sockets are free again.

I guess you Dockstar doesn't have an RTC-clock either?



Edited 1 time(s). Last edit at 03/31/2015 07:39PM by JohnW.

I have 3 GFHome and they are running OK with RTC. Fwiw, you could also try SNTP in U-boot. It is a good solution, no need to run ntpdate.

And the dockstar does not have RTC.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 03/31/2015 08:35PM by bodhi.

Setting the correct date is certainly a complicated process in these little ARM boxes without a RTC.

Yes, the SNTP in uBoot will prevent you from seeing all those 1969 timestamps on files that get written or created on each boot, but will it result in an accurate time after reboot? My short experimentation with it seems to show that it won't. What happens is that the SNTP module will fetch the current network time and write it into some register in the hardware adjudicated to be the RTC, but since a real RTC does not exist, the time will not increment until the kernel is booted. Thus, the kernel will see a time that is several-to-many seconds old, and if you are interested in sub-second accuracy, you'll still have to resync NTP after the kernel is booted.

I ran into the following problem on squeeze (later upgraded to wheezy): I run DNS on my Plugs, plus NTP. DNS comes up before the Ethernet becomes available, and seeing an unreasonable (1969) system time, it immediately goes into SVRFAIL. NTP, OTOH, requires a DNS in order to reach the NTP server and can't set the time until it becomes available -- a true Catch-22. My workaround involves pointing the Plug's DNS servers to my local router initially. The next issue is that when the Ethernet comes up, NTP is sitting on its port, conflicting with the ntpdate-debian command, which networking is relying on to set the date. I worked around this problem by replacing the call to ntpdate-debian in /etc/network/if-up.d" with "invoke-rc.d --quiet ntp restart || true". (I also had to set the "-g" option in /etc/default/ntp.) This has worked for me for the past two+ years, but it is an awful kludge.

I just recently got SNTP capabilities in the new uBoot, and have not experimented with how DNS/bind will react to an almost correct date. I expect it will be quite happy, which may make using SNTP worthwhile, even if NTP has to jump the date by several seconds later in the boot.

But, as I said, setting the date on boot for a machine that has no RTC is anything but straightforward.

restamp Wrote:
-------------------------------------------------------

> But, as I said, setting the date on boot for a
> machine that has no RTC is anything but
> straightforward.

Could be. But I have all my boxes without RTC and with RTC, never failed to set the date. Just wonder what could be the difference?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Perhaps the time server that you use would make a difference? When your ntpd failed to start, what was the time relative to when ntpdate finished? and what versions are ntpd and ntpdate?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Don't misunderstand me, even before I started hacking on the NTP/DNS/Networking, it would eventually come up and stabilize; it just took it a long time. (It's been a while, but I seem to recall it could take as long as 5-10 minutes, which is probably related to some retry timeout in NTP.)

Bodhi, I think the difference is that the PogoPlugs I am booting are serving up multiple functions, and these functions rely on one another, so it becomes a chicken-and-egg problem. Are you running DNS servers for your LAN from your Plugs? If your DNS servers are external to your Plugs, this probably won't be as much of a problem, although there is still the issue of ntpd and ntpdate fighting each other for resources, and if you're not spawning ntpd, it likely will not be a problem at all.

@restamp,

I see what you meant.

FWIW, I recall that I used to have a setup with only Debian ntp pool servers, sometime it took forever to sync. I switched to a group of specific ntp servers that geographically near me (only hope it will be faster) , and have never seen the long wait again. Also, I use Google DNS 8.8.8.8 in the resolver.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)