I just noticed the time is wrong on my Pi (heavily modified version of Raspbian).
syslog shows DNS issues: Mar 22 12:08:00 pi daemon.err ntpd[569]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
.. but I can ping 1.debian.pool.ntp.org just fine,
/etc/resolv.conf lists 8.8.8.8 and 8.8.4.4 so it ought to work.
Suggestions?
I don't want to reboot or anything until I understand the cause.
On Sun, Mar 22, 2020 at 10:46:53AM +0000, Mark Rogers wrote:
I just noticed the time is wrong on my Pi (heavily modified version of Raspbian).
syslog shows DNS issues: Mar 22 12:08:00 pi daemon.err ntpd[569]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
.. but I can ping 1.debian.pool.ntp.org just fine,
/etc/resolv.conf lists 8.8.8.8 and 8.8.4.4 so it ought to work.
Suggestions?
I don't want to reboot or anything until I understand the cause.
Something awry at 'the other end' maybe, I just tried:-
chris$ host debian.pool.ntp.org chris$
Very odd! Same on all my systems. Also just tried it from my virtual server running on Gandi in France, same [non-] result. Other names resolve OK.
On Sun, 22 Mar 2020 at 11:09, Chris Green cl@isbd.net wrote:
Something awry at 'the other end' maybe, I just tried:-
chris$ host debian.pool.ntp.org chris$
Try: host 1.debian.pool.ntp.org
It looks like you need the subdomain.
But the subdomain is listed in my config (and the logs show it is being used, indeed they try multiple subdomains being tried but all failing) yet I can look them up from the terminal.
On Sun, Mar 22, 2020 at 11:16:58AM +0000, Mark Rogers wrote:
On Sun, 22 Mar 2020 at 11:09, Chris Green cl@isbd.net wrote:
Something awry at 'the other end' maybe, I just tried:-
chris$ host debian.pool.ntp.org chris$Try: host 1.debian.pool.ntp.org
It looks like you need the subdomain.
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
I've tried several other sites where I know there is a.b.c.d and b.c.d and they all return IPs for both.
Interestingly see:-
chris$ host pool.ntp.org pool.ntp.org has address 51.140.97.99 pool.ntp.org has address 162.159.200.123 pool.ntp.org has address 109.74.206.120 pool.ntp.org has address 217.114.59.3 chris$ host debian.pool.ntp.org chris$ host 1.debian.pool.ntp.org 1.debian.pool.ntp.org has address 195.171.43.10 1.debian.pool.ntp.org has address 134.0.16.1 1.debian.pool.ntp.org has address 162.159.200.1 1.debian.pool.ntp.org has address 46.227.200.68 chris$
There are som intersting quirks in DNS now as IPv6 becomes more common, one thing it does often is cause a delay in one's first DNS lookup after not using it for a while. It can depend on what library call is being used to get the IP, some try both IPv4 and IPv6, some try only IPv4. Maybe the above oddity is another artefact of the same.
The response for debian.pool.ntp.org is definitely a bit wonky, I just tried nslookup too:-
chris$ nslookup debian.pool.ntp.org Server: 127.0.0.53 Address: 127.0.0.53#53
Non-authoritative answer: *** Can't find debian.pool.ntp.org: No answer
chris$ nslookup nurdle.isbd.uk Server: 127.0.0.53 Address: 127.0.0.53#53
** server can't find nurdle.isbd.uk: NXDOMAIN
On Sun, 22 Mar 2020 at 16:33, Chris Green cl@isbd.net wrote:
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
To my knowledge there's no requirement that higher level domains should resolve. (For example, that would imply that you should be able to resolve "org" before you can resolve "ntp.org".)
It's an interesting feature of the configuration but I think it's a red herring as far as my ntpd's inability to resolve 1.debian.pool.ntp.org is concerned.
On Sun, Mar 22, 2020 at 05:02:27PM +0000, Mark Rogers wrote:
On Sun, 22 Mar 2020 at 16:33, Chris Green cl@isbd.net wrote:
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
To my knowledge there's no requirement that higher level domains should resolve. (For example, that would imply that you should be able to resolve "org" before you can resolve "ntp.org".)
No, I agree, but it shouldn't return 'nothing' should it? Non-existent domains return NXDOMAIN.
On Sun, 22 Mar 2020 18:32:05 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Mar 22, 2020 at 05:02:27PM +0000, Mark Rogers wrote:
On Sun, 22 Mar 2020 at 16:33, Chris Green cl@isbd.net wrote:
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
To my knowledge there's no requirement that higher level domains should resolve. (For example, that would imply that you should be able to resolve "org" before you can resolve "ntp.org".)
No, I agree, but it shouldn't return 'nothing' should it? Non-existent domains return NXDOMAIN.
The domain is not non existent - the A record is empty.
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------
On Sun, Mar 22, 2020 at 06:46:30PM +0000, mick wrote:
On Sun, 22 Mar 2020 18:32:05 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Mar 22, 2020 at 05:02:27PM +0000, Mark Rogers wrote:
On Sun, 22 Mar 2020 at 16:33, Chris Green cl@isbd.net wrote:
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
To my knowledge there's no requirement that higher level domains should resolve. (For example, that would imply that you should be able to resolve "org" before you can resolve "ntp.org".)
No, I agree, but it shouldn't return 'nothing' should it? Non-existent domains return NXDOMAIN.
The domain is not non existent - the A record is empty.
OK, but the 'successful' lookup with no result could confuse some software couldn't it? dig shows 'NOERROR', host returns nothing, nslookup says "*** Can't find debian.pool.ntp.org: No answer", it's not very consistent. :-)
On Sun, 22 Mar 2020 18:52:27 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Mar 22, 2020 at 06:46:30PM +0000, mick wrote:
On Sun, 22 Mar 2020 18:32:05 +0000 Chris Green cl@isbd.net allegedly wrote:
On Sun, Mar 22, 2020 at 05:02:27PM +0000, Mark Rogers wrote:
On Sun, 22 Mar 2020 at 16:33, Chris Green cl@isbd.net wrote:
Yes, but 'host debian.pool.ntp.org' shouldn't just return nothing should it?
To my knowledge there's no requirement that higher level domains should resolve. (For example, that would imply that you should be able to resolve "org" before you can resolve "ntp.org".)
No, I agree, but it shouldn't return 'nothing' should it? Non-existent domains return NXDOMAIN.
The domain is not non existent - the A record is empty.
OK, but the 'successful' lookup with no result could confuse some software couldn't it? dig shows 'NOERROR', host returns nothing, nslookup says "*** Can't find debian.pool.ntp.org: No answer", it's not very consistent. :-)
Different tools will often give apparently different answers. But they are consistent.
Take a look at the full response to a dig query. It clearly shows no A record.
--------------------------------------------------------------------- Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 https://baldric.net/about-trivia ---------------------------------------------------------------------
The diversion to intricacies of DNS configuration didn't get my any closer, nor did reboots and lots of Googling (lots of people get these errors, but they go away once they fix DNS or Internet connection issues, neither of which I have).
But I have found a clue that I don't know what to do with:
If I stop the ntp service and run ntpd manually, it resolves the iP addresses correctly: sudo systemctl stop ntp sudo ntpd -g -u 109:113
If I kill ntpd and restart it via systemctl it fails again. So it is something to do with how it is being run as a service.
I'm still stuck but in a different place now, any suggestions?
Mark
-- Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450 Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
On Tue, 24 Mar 2020 at 08:45, Mark Rogers mark@more-solutions.co.uk wrote:
If I stop the ntp service and run ntpd manually, it resolves the iP addresses correctly: sudo systemctl stop ntp sudo ntpd -g -u 109:113
If I kill ntpd and restart it via systemctl it fails again. So it is something to do with how it is being run as a service.
I found the problem.
The systemd unit file includes PrivateTmp=true and that is what was breaking it for me.
I did mention that the Pi was heavily modified Rasbian, right? It's built to use a read-only filesystem, but all my testing was being done with it mounted read-write so I'm not sure why this was breaking. But I assume something about the way the partitions are mounted might be breaking systemd (it's something to look further into now I have discovered it).
Mark
On Tue, 2020-03-24 at 09:35 +0000, Mark Rogers wrote:
On Tue, 24 Mar 2020 at 08:45, Mark Rogers mark@more-solutions.co.uk wrote:
If I stop the ntp service and run ntpd manually, it resolves the iP addresses correctly: sudo systemctl stop ntp sudo ntpd -g -u 109:113
If I kill ntpd and restart it via systemctl it fails again. So it is something to do with how it is being run as a service.
I found the problem.
The systemd unit file includes PrivateTmp=true and that is what was breaking it for me.
First we kill Poettering.
On Tue, 24 Mar 2020 at 15:06, Huge huge@huge.org.uk wrote:
First we kill Poettering.
Life was so much easier before!
I'd forgotten but the reason I even have ntp installed is because the systemd-timesync daemon really doesn't like a read-only filesystem.
ntp has worked for ages though, even in this configuration. I assume something has been "improved".
On Tue, Mar 24, 2020 at 05:36:36PM +0000, Mark Rogers wrote:
On Tue, 24 Mar 2020 at 15:06, Huge huge@huge.org.uk wrote:
First we kill Poettering.
Life was so much easier before!
I'd forgotten but the reason I even have ntp installed is because the systemd-timesync daemon really doesn't like a read-only filesystem.
ntp has worked for ages though, even in this configuration. I assume something has been "improved".
Yes, there do seem to be quite a few rather subtle faults caused by systemd. I'm chasing a bug which causes a 5 second DNS delay on only the first DNS look-up after boot.
On Tue, 2020-03-24 at 17:36 +0000, Mark Rogers wrote:
On Tue, 24 Mar 2020 at 15:06, Huge huge@huge.org.uk wrote:
First we kill Poettering.
Life was so much easier before!
I'd forgotten but the reason I even have ntp installed is because the systemd-timesync daemon really doesn't like a read-only filesystem.
One of my biggest hates of systemd; it keeps subsuming years old standard Unix subsystems.
-
Chris Green -
Huge -
Mark Rogers -
mick