[7.0.0-beta.2] ntpd spam

18 hours ago, JorgeB said:

Anyone affected please post together with the diags the output of:

 

cat /etc/ntp.conf | grep interface

 

 

 

i see the issue has been figured out though, but i posted just for clarity what mine was

Having this issue as well

 

root@Unraid:~# cat /etc/ntp.conf | grep interface
interface ignore wildcard
interface ignore ipv6
interface listen 10.0.2.3 # bond0

The same here

 

root@THOR:~# cat /etc/ntp.conf | grep interface
interface ignore wildcard
interface ignore ipv6
interface listen 192.168.178.44 # br0

On 7/20/2024 at 1:45 PM, thecode said:

I can confirm, tested twice, even without reboot.

 

Host access to custom networks enabled = "on 1 br0 -> *multiple*" by ntpd

Host access to custom networks disabled = not logged

This fixed for me the Error

This should be fixed for next release, but as a workaround for anyone needing "host access to custom networks enabled", typing:

 

/etc/rc.d/rc.ntpd restart

 

Should stop the spam

2 hours ago, JorgeB said:

This should be fixed for next release, but as a workaround for anyone needing "host access to custom networks enabled", typing:

 

/etc/rc.d/rc.ntpd restart

 

Should stop the spam

 

Just one note, I think that after restart the NTP client is not syncing anymore.

 

Web UI will show:

 

 

Checking source for NTP sync:

root@Sam:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*LOCAL(0)        .LOCL.          10 l  135  256  377    0.000   +0.000   0.000
 time2.google.co .INIT.          16 u    - 1024    0    0.000   +0.000   0.000

 

Last checking on a server before restarting the ntpd:

 

root@Fanta:~# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l 168m   64    0    0.000   +0.000   0.000
*time1.google.co .GOOG.           1 u   70  128  377   67.400  +837.45 837.667

 

I know that because I did something similar in the past, if you edit anything in the time settings on the Web UI (such as change NTP server, change it back and press apply) it also restart the ntpd but I noticed that the server start to create drift over time

 

57 minutes ago, thecode said:

Just one note, I think that after restart the NTP client is not syncing anymore.

How long does it take to start drifting? I did a restart and appear to remain synced.

On 8/30/2024 at 12:57 PM, JorgeB said:

How long does it take to start drifting? I did a restart and appear to remain synced.

 

The drift depends on the accuracy of the clock of your server, for the server I tested it will accumulate about 10mSec a day, that is not critical, but I have seen servers which generate more than a second a day. Before restart this server will stay synced with less than 0.5mSec offset.

Also if I am reading the output correctly, before restart the source for sync is shown as an external server and after restart it shows "LOCAL(0)" which means the time is not synced to a server.

I know there is no release yet and there is a WIP, but just as a feedback, I applied https://github.com/unraid/webgui/commit/12828eec63a27d446c06e95d85f6361ad02fb53d to one of the servers, & reloaded the ntpd. As explained above it showed unsynchronized for almost two days (and accumulated around 30mSec drift), during that time the "*multiple*" message was not logged, however after two days the message returned, the clock status got back to synchronized and the drift fixed to 0.4mSec. The log does not show that the ntpd restarted however the time the spam started back is just after one of the dockers was restarted which creates a veth interface.

I think I will be able to reproduce it again if needed.