Archive > 20.1 Legacy Series
ntpd both running and not running?
danb35:
I recently installed OPNsense (currently on 20.1.9), and it's working well, though with a few oddities. One of them is that, at least from what the web UI shows, the ntpd service won't start. The dashboard shows:
(see attachment)
...and in what's probably the relevant section, the log shows:
(see other attachment)
And indeed, there is a process listening on *:123, but it's ntpdate, not ntpd:
--- Code: ---root@opnsense:~ # sockstat -l | grep :123
root ntpdate 77157 4 udp6 *:123 *:*
root ntpdate 77157 5 udp4 *:123 *:*
root@opnsense:~ # service ntpdate status
Cannot 'status' ntpdate. Set ntpdate_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'.
root@opnsense:~ # service ntpdate onestatus
ntpdate is not running.
--- End code ---
Something's strange--what should the next steps be to track this down?
danb35:
A little more searching has found https://forum.opnsense.org/index.php?topic=9980.0 in German, which seems to be about the same problem. Like in that thread, I find that the PID of the ntpdate process is constantly changing. I likewise have nothing relevant in /etc/rc.conf, and don't have rc.conf.local at all.
Edit: When I run ps aux, I see this in the list:
--- Code: ---root 15508 0.0 0.1 1058416 3136 - Ss 12:58 0:00.01 /bin/sh /usr/local/etc/inc/plugins.inc.d/ntpd/ntpdate_sync_once.
--- End code ---
I'm having a little trouble parsing that script, but from what I can tell it's supposed to try three times to sync and then give up if it failed. But the system uptime is a couple of days, it's still coming up in the "ps aux" listing, and new ntpdate processes keep getting started.
Interestingly, there's nothing at all in the ntpd log since some time yesterday, even though I'd tried to start the service again since then.
danb35:
Anyone?
franco:
Hi there,
ntpdate_sync_once.sh is an historic (and arcane) bit of software that defers NTP daemon start and sets the right time through ntpdate before starting NTP daemon itself. Some of this stems from the fact that NTP daemon may only slowly update time or fail to do so if drift is too wide.
Problem is it looks "broken" once you startup the device or after applying interface settings etc., but in the end ntpdate finishes and ntpd starts properly without further need to handle it.
Cheers,
Franco
danb35:
--- Quote ---in the end ntpdate finishes and ntpd starts properly without further need to handle it.
--- End quote ---
So how long does this take? Because this system is now at a week of uptime, and repeated ntpdate processes are still spawning, blocking ntpd from starting.
Navigation
[0] Message Index
[#] Next page
Go to full version