ntpd keeps Soliciting pool server

[Manuel López-Ibáñez]

ntpd keeps printing "Soliciting pool server" in the syslog (once every 5 seconds).

$ ntpq -c pe
     remote refid st t when poll reach delay offset jitter
==============================================================================
 0.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
 1.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
 2.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
 3.ubuntu.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000
 ntp.ubuntu.com .POOL. 16 p - 64 0 0.000 0.000 0.000

$ sudo ntpq -c rv
associd=0 status=c016 leap_alarm, sync_unspec, 1 event, restart,
version="ntpd 4.2.8p4@1.3265-o Fri Jul 6 20:10:51 UTC 2018 (1)",
processor="x86_64", system="Linux/4.15.0-33-generic", leap=11,
stratum=16, precision=-24, rootdelay=0.000, rootdisp=0.360, refid=INIT,
reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
clock=df6ee808.934d239d Mon, Oct 15 2018 11:18:48.575, peer=0, tc=3,
mintc=3, offset=0.000000, frequency=6.224, sys_jitter=0.000000,
clk_jitter=0.000, clk_wander=0.000

I have changed nothing in the default configuration of ntp or the firewall.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ntp 1:4.2.8p4+dfsg-3ubuntu5.9
ProcVersionSignature: Ubuntu 4.15.0-33.36~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-33-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
CurrentDesktop: KDE
Date: Mon Oct 15 11:17:45 2018
InstallationDate: Installed on 2018-04-20 (177 days ago)
InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 (20170801)
SourcePackage: ntp
UpgradeStatus: No upgrade log present (probably fresh install)

[Paul Gear (paulgear)]

Hi Manuel, ntpd keeps printing "Soliciting pool server" in syslog because it can't contact any of the ntp servers in the pool. This is most likely a local configuration problem on your machine or network, or your service provider's network.

Here are some commands that should help work out where the problem lies.

# Check whether your system can resolve DNS names correctly:
dig 0.ubuntu.pool.ntp.org

# Check whether you can ask for time from these hosts:
ntpdate -d 0.ubuntu.pool.ntp.org

To run the above commands successfully, you'll need the dnsutils and ntpdate packages installed. Here's what a successful run might look like (abbreviated): https://pastebin.ubuntu.com/p/zmzgj4nrwS/

If the dig fails, you've got a problem with DNS resolution. Check for a broken local DNS resolver or upstream DNS server.

If the dig succeeds but the ntpdate fails, you might have an outbound firewall blocking access or connection tracking problem in that firewall.

If both of the above succeed, but NTP still fails, your problem is likely a firewall blocking outbound NTP access.

The firewalls might be on your local machine, your local network, or your ISP's network (unfortunately, the last is more common that it should be).

Other causes might be a local apparmor profile override which prevents ntpd from doing DNS lookups.

Hope this helps you track it down!

[Manuel López-Ibáñez (manuellopezibanez)]

Both of them work. I don't understand how the last command can work and I may still be behind a firewall.

Also:

$ timedatectl status
 Network time on: yes
NTP synchronized: yes

So it seems it is synchronized, it just re-tries too frequently.

[Manuel López-Ibáñez (manuellopezibanez)]

It is transmitting and receiving, so it doesn't look like it is blocked:

Looking for host 0.ubuntu.pool.ntp.org and service ntp
host found : 85.199.214.102
transmit(85.199.214.102)
receive(85.199.214.102)
transmit(145.239.118.233)
receive(145.239.118.233)
transmit(139.162.219.252)
receive(139.162.219.252)
transmit(185.53.93.157)
receive(185.53.93.157)
transmit(85.199.214.102)
receive(85.199.214.102)
transmit(145.239.118.233)
receive(145.239.118.233)
transmit(139.162.219.252)
receive(139.162.219.252)
transmit(185.53.93.157)
receive(185.53.93.157)
transmit(85.199.214.102)
receive(85.199.214.102)
transmit(145.239.118.233)
receive(145.239.118.233)
transmit(139.162.219.252)
receive(139.162.219.252)
transmit(185.53.93.157)
receive(185.53.93.157)
transmit(85.199.214.102)
receive(85.199.214.102)
transmit(145.239.118.233)
receive(145.239.118.233)
transmit(139.162.219.252)
receive(139.162.219.252)
transmit(185.53.93.157)
receive(185.53.93.157)
server 85.199.214.102, port 123

[Nathan Stratton Treadway (nathanst)]

On Fri, Oct 19, 2018 at 14:36:35 -0000, Manuel López-Ibáñez wrote:
> Both of them work. I don't understand how the last command can work and
> I may still be behind a firewall.

"ntpdate -d" sends packets using an unprivileged source port, so
a firewall could allow those packets but block outgoing packets from
ntpd itself, which use a source port of 123....

       Nathan

[Nathan Stratton Treadway (nathanst)]

On Fri, Oct 19, 2018 at 14:36:35 -0000, Manuel López-Ibáñez wrote:
> $ timedatectl status
> Network time on: yes
> NTP synchronized: yes
>
> So it seems it is synchronized, it just re-tries too frequently.

(I am not sure what exactly timedatectl looks at when checking the
status of ntpd, but the fact that in the ntpq output all your servers
show a stratum of 16 and a reach of 0 means that ntpd is defintely not
synchronized to anything....

When it's functioning properly, your pool server stratums should show up
somewhere between 1 and 3 or 4, and the reach will be an octal flag
showing progressively more bits turned on as responses are received from
the server in question [e.g. 1, 3, 7, 17, 37... on until 377, assuming
that there aren't any lost packets along the way].)

       Nathan

[Ian Brown (snakebyter)]

I just wanted to chime in here as I was having the exact same problem.

Turned out to be because of some configuration changes I made to ntp.conf in an attempt to prevent ntpd from listening on any of my network interfaces (security paranoid):

interface ignore wildcard
interface listen 127.0.0.1

Apparently ntpd also uses these settings for outgoing connection attempts too.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Joe Henley (joehenley)]

Same problem on my PC running: Linux Mint 19.2 Mate.