[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.

 

Still an issue in Beta 3

is there maybe a temporary fix? my whole syslog is spammed by this.

same here ...

I believe that restarting ntp worked for a user, see if it helps:

 

/etc/rc.d/rc.ntpd restart

 

11 hours ago, JorgeB said:

I believe that restarting ntp worked for a user, see if it helps:

 

/etc/rc.d/rc.ntpd restart

 

I tried that, it stopped the spam but it seemed like it stopped syncing time too.

The servers showing INIT forever (not using the Google server).

The log is filled with Oct  6 11:24:27 Server ntpd[11986]: 192.168.1.100 on 1 eth0 -> *multiple* and I have host access to custom networks enabled.

14 minutes ago, Niklas said:

but it seemed like it stopped syncing time too

I think it should sync up again after some time, let it run for a while and report back.

50 minutes ago, JorgeB said:

I think it should sync up again after some time, let it run for a while and report back.

 

Usually ntpd will do the initial sync very fast.

This is after restart but I'll wait for a while.

beta3 btw.

 

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l   41   64    7    0.000   +0.000   0.000
 sth1.ntp.netnod .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 sth2.ntp.netnod .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 gbg1.ntp.netnod .INIT.          16 u    -   64    0    0.000   +0.000   0.000
 svl1.ntp.netnod .INIT.          16 u    -   64    0    0.000   +0.000   0.000

vs normal

 

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l   8h   64    0    0.000   +0.000   0.000
+sth1.ntp.netnod .PPS.            1 u  293 1024  377    2.744   +0.011   0.053
+sth2.ntp.netnod .PPS.            1 u  355 1024  377    3.336   +0.079   0.095
-gbg1.ntp.netnod .PPS.            1 u  357 1024  377    9.849   -0.174   0.112
*svl1.ntp.netnod .PPS.            1 u  314 1024  377    7.765   +0.022   0.083

 

Edited October 6 by Niklas

41 minutes ago, JorgeB said:

I think it should sync up again after some time, let it run for a while and report back.

@JorgeB If you read the thread history, mainly from 

 

I reported that it would not sync back (I manually applied the patch in beta3 before it was released), when you restart the ntpd it stops synchronizing, I restarted the ntpd client 12 hours ago, it still shows LOCAL as source and GUI shows the time is not synchronized. 

38 minutes ago, thecode said:

I reported that it would not sync back

Sorry, forgot about that post, in tat case I don't think there's any solution or workaround for now.

 

 

The sync is back but also the ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*

10 minutes ago, Niklas said:

The sync is back but also the ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*

Similar happened to me in the past (mentioned above) 

 

https://forums.unraid.net/bug-reports/prereleases/beta-72-ntpd-r3123/?do=findComment&comment=29895

Edited October 6 by thecode
Add link

1 hour ago, Niklas said:

The sync is back but also the ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*

 

I didn't realize the beta.3 already does an ntp restart after array start, and with this beta, I can no longer reproduce this issue, even with "Host access to custom networks" enabled, like I could with beta.2, meaning that likely, that is not the only thing causing this issue, so anyone who still sees the ntp spam with beta.3 please post new diags to see if there's something else in common.

Just now, JorgeB said:

I can no longer reproduce this issue

Or maybe it takes longer? before it was every 5 minutes after array start, it will be visible in the diags anyway.

10 minutes ago, JorgeB said:

Or maybe it takes longer? before it was every 5 minutes after array start, it will be visible in the diags anyway.

 

Every 5 yes.
 

Oct  6 18:09:38 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:14:39 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:19:40 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:23:59 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:29:00 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:34:01 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:39:02 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:44:03 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:49:04 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:54:05 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 18:59:06 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*
Oct  6 19:04:07 Server ntpd[729198]: 192.168.1.100 on 1 eth0 -> *multiple*

 

1 hour ago, JorgeB said:

please post new diags to see if there's something else in common.

 

unraid-1-diagnostics-20241006-2012.zip