I was looking in syslog to look into an audio issue and I see a hell of a lot of the Soliciting pool server ntp daemon messages. I've run other linux in past and never recall seeing so many ntp log messages. Is this due to a new network issue perhaps, is it common for Mint, is there a way to shush them if it is "common"?
I've changed carriers and router hardware since those days, so I do not rule out something in my net. I have no problems accessing internet or playing online games etc.
The messages mean your ntpd server is looking for more time sources to sync to. Seeing a couple of them is expected, especially after reconnecting to the network after an outage or a restart, but if your ntpd and your network connection are running smoothly, you shouldn't be seeing more than a few per day. If you have several every few minutes, it's likely a problem.
Does your ntpd connect to peers and sync time successfully? You can check for that using ntpq. Look at the list of peers in ntpq -c pe and the reported stratum and reftime in ntpq -c rv. Stratum of 16 means “not synchronized”.
This:
user@localhost $ ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
de.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.002
user@localhost $ ntpq -c rv
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd [email protected] Tue Jun 20 08:08:18 UTC 2017 (1)",
processor="x86_64", system="Linux", leap=11, stratum=16,
precision=-23, rootdelay=0.000, rootdisp=0.090, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
clock=dde6bdf4.dec8453b Fri, Dec 22 2017 0:10:44.870, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=4.981, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000
means your NTP doesn't actually work (in this case because I've just started it up), while this:
user@localhost $ ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
cz.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000 0.002
+mail.nettel.cz 195.113.144.201 3 u 4 64 377 5.215 -0.842 0.332
*fedecks.wuji.cz 195.113.144.238 2 u 61 64 377 2.121 -2.005 0.171
-lx.ujf.cas.cz .GPS. 1 u 62 64 177 2.662 -0.714 0.215
-pyrrha.fi.muni. 195.113.144.238 2 u 63 64 177 7.445 -0.697 0.340
-host-81-200-57- 192.168.3.246 2 u 55 64 177 15.792 0.098 1.160
cz.inthouse.clo 147.231.2.6 2 u 47 64 17 5.338 -0.266 0.461
user@localhost $ ntpq -c rv
associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync,
version="ntpd [email protected] Sat Jul 29 07:38:14 UTC 2017 (1)",
processor="ppc", system="Linux", leap=00, stratum=2,
precision=-19, rootdelay=2.652, rootdisp=4.409, refid=147.231.100.5,
reftime=dde6be4a.f90912d6 Fri, Dec 22 2017 0:12:10.972,
clock=dde6be4d.12f27b56 Fri, Dec 22 2017 0:12:13.074, peer=10703, tc=6,
mintc=3, offset=-0.387828, frequency=-254.539, sys_jitter=1.572660,
clk_jitter=0.456, clk_wander=0.098
means your NTP works correctly.
If it doesn't sync and stays that way for a long time, you likely have a network or configuration problem. Look at man 5 ntp.conf for help and at the NTP.org support page about configuration for examples. In my case, the reason for the unending “Soliciting pool server” spam was the nopeer directive, which has to be off for pool servers.
To me it just seems like NTP is doing its job: requesting time data from NTP servers, then posting that in the syslog. Nothing to worry about.
