This hack does work, but it only lasts until you reboot VyOS. When the OS comes back up, you'll need to do this again.

I have just verified that this behavior persists in the latest dev build (from the current branch), 999.201609230235.

I tried adding this to /config/scripts/vyatta-postconfig-bootup.script:

# Run ntpd; see https://phabricator.vyos.net/T155
/usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 105:112

But that doesn't quite do the trick. It does start up ntpd, but VyOS doesn't know about it.

When ntpd starts, it seems to see the previous version of /etc/ntp.conf, but then the VyOS config system overwrites /etc/ntp.conf with an essentially empty version. That means that the next time you restart ntpd or VyOS, ntpd will get the empty ntp.conf, and not work. Worse, the make-trivial-changes-to-system ntp server trick no longer has any effect.

So this is not a viable workaround.

I've written a handy script to start ntpd manually:

#!/bin/vbash
source /opt/vyatta/etc/functions/script-template

configure
/opt/vyatta/sbin/vyatta_update_ntp.pl
exit

/usr/sbin/invoke-rc.d ntp start

However, if I arrange for this script to be invoked at startup via /config/scripts/vyatta-postconfig-bootup.script, it doesn't work. (It creates an /etc/ntp.conf that contains just the contents of vyatta-cfg-system/sysconf/ntp.conf plus the line # Servers, and so ntp doesn't start up.) But worse, I am unable to enter configuration mode from an ssh login at that point:

gadams@core-rt:~$ configure
Failed to set up config session
gadams@core-rt:~$

My router is apparently hosed. Removing it from vyatta-postconfig-bootup.script and rebooting cured that.

However, if I log in and execute that script via sudo immediately after startup, ntp will start up fine, with correct servers listed in /etc/ntp.conf.

So, what is it about the conditions at startup that cause /etc/ntp.conf to be improperly written?

Can you test if this happens with SNMP in this particular 1.2.0-beta1 build as well, and maybe in the preview images? I may have just had it happen after rebooting an instance...

Thanks.

Hmm. Things are afoot.

I've been playing with the latest lithium (dev) build (999.201609230235), and now ntpd does start on boot. And the /etc/ntpd.conf file has the contents I'd expect. However, it is not able to make any connections to any remote servers.

$ ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 clock.trit.net  .INIT.          16 -    -  512    0    0.000    0.000   0.000
 104.131.53.252  .INIT.          16 -    -  512    0    0.000    0.000   0.000
 orchid.sidereal .INIT.          16 -    -  512    0    0.000    0.000   0.000
 eterna.binary.n .INIT.          16 -    -  512    0    0.000    0.000   0.000
*olaf.avernus.co 204.9.54.119     2 u   24   64  377    0.162  -16.298   5.504

This seems to have something to do with the state of routing on startup; when ntpd starts, no network interfaces are up. Later, ntpd is able to connect only to a directly-attached ntp server (olaf, above). That's suspicious.

Issuing the command systemctl restart ntp after that fixes it:

$ ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*clock.trit.net  43.77.130.254    2 u   11   64  177   17.632   19.562  43.529
+104.131.53.252  209.51.161.238   2 u   10   64  177   76.361   -8.272  31.822
+orchid.sidereal 200.98.196.212   2 u    9   64  177   84.956   17.080  39.592
+eterna.binary.n 216.229.4.69     3 u    8   64  177   70.008   21.231  14.337
+olaf.avernus.co 204.9.54.119     2 u    9   64  177    0.141   -7.596  22.159