[arch-general] OpenNTPd not correcting time on boot
Hi, First time posting so forgive me if I get it wrong. (This is already a resend because I used the wrong email previously!) I'm using OpenNTPd as a time server for my local network, but I have a slight issue. I run it on my Raspberry Pi which lacks a hardware clock, so every time I boot it, it thinks the time is 1970. In the systemd init file, openntpd.service, it runs the ntpd daemon with the '-s' option, which tell it that if the time is really far out of sync, just update it straight to the time that the server has. The problem is, this doesn't happen after boot. If I manually set the time with 'date -s @0000000000' and then restart the openntpd service it will work, but not automatically after boot up. I suspect it might be that it's not able to talk to a server because it's starting the service before the network is ready or something, but I'm using a static IP and have told openntpd.service that "wants" and "after" both == network.target. Any ideas? Joe -- *:wq!*
On Tue, Jul 2, 2013 at 11:37 PM, Joe Eaves <jinux@alluha.net> wrote:
Hi,
First time posting so forgive me if I get it wrong. (This is already a resend because I used the wrong email previously!)
I'm using OpenNTPd as a time server for my local network, but I have a slight issue. I run it on my Raspberry Pi which lacks a hardware clock, so every time I boot it, it thinks the time is 1970.
In the systemd init file, openntpd.service, it runs the ntpd daemon with the '-s' option, which tell it that if the time is really far out of sync, just update it straight to the time that the server has. The problem is, this doesn't happen after boot.
If I manually set the time with 'date -s @0000000000' and then restart the openntpd service it will work, but not automatically after boot up.
I suspect it might be that it's not able to talk to a server because it's starting the service before the network is ready or something, but I'm using a static IP and have told openntpd.service that "wants" and "after" both == network.target.
Any ideas?
Joe
-- *:wq!*
Hi, I did not test this, but you may want to make it "want" network-online.target instead of network.target. Cheers, -- Maxime
On 3 July 2013 08:36, Maxime GAUDUIN wrote:
I did not test this, but you may want to make it "want" network-online.target instead of network.target.
Cheers,
-- Maxime
Hi, I tried this but it didn't work. I set both 'wants' and 'after' to network-online.target, should I only have one set? Is there maybe a later target I can have it wait for? -- :wq!
On Wed, Aug 7, 2013 at 1:04 PM, Joe Eaves <jinux@alluha.net> wrote:
On 3 July 2013 08:36, Maxime GAUDUIN wrote:
I did not test this, but you may want to make it "want" network-online.target instead of network.target.
Cheers,
-- Maxime
Hi,
I tried this but it didn't work. I set both 'wants' and 'after' to network-online.target, should I only have one set?
Is there maybe a later target I can have it wait for?
Try to add iburst. I have something like that: pool europe.pool.ntp.org iburst Cheers, -- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A
On 7 August 2013 15:49, Sébastien Luttringer wrote:
Try to add iburst.
I have something like that: pool europe.pool.ntp.org iburst
Cheers,
Hi, OpenNTPd seems not to support that option, so it didn't work. I tried switching to NTP, which does support 'iburst', and now it all works how I want it to. NTP fails as well if I don't include the 'iburst' option, so it seems odd to me that OpenNTPd wouldn't support anything even similar. Doesn't matter though, all happy now :) Thanks, Joe -- :wq!
On Thursday 08 Aug 2013 13:49:26 Joe Eaves wrote:
OpenNTPd seems not to support that option, so it didn't work.
I tried switching to NTP, which does support 'iburst', and now it all works how I want it to.
NTP fails as well if I don't include the 'iburst' option, so it seems odd to me that OpenNTPd wouldn't support anything even similar.
Doesn't matter though, all happy now :)
I remember I switched to stock NTP from openntpd a while back because of a discussion I saw on this mailing list concerning its suitability for cross- platform use. I think it was something about its origins in one of the BSDs, and how the maintainers responsible for ensuring its correct operation on other platforms (including Linux) had more or less abandoned it. I don't know if this is still the case? Regardless, I originally chose openntpd because it seemed easier to configure, but I've since realised that's not really true. NTP itself is perfectly simple, and definitely *is* very well supported. Paul
On 8 August 2013 14:33, Paul Gideon Dann <pdgiddie@gmail.com> wrote:
Regardless, I originally chose openntpd because it seemed easier to configure, but I've since realised that's not really true. NTP itself is perfectly simple, and definitely *is* very well supported.
Paul
That was my reasoning too. I think I'm leaning that way too now though. There are more options, it's more expensive in time to configure, but from taking a proper look I don't think it will be 'harder'. -- :wq!
Am 03.07.2013 09:36, schrieb Maxime GAUDUIN:
I did not test this, but you may want to make it "want" network-online.target instead of network.target.
I don't think we have any services by default that make network-online.target function. The actual problem is that openntpd does not work properly and ntpd should be used instead. At least I stopped using openntpd after realizing that it simply didn't work. As a plus, ntpd deals with appearing and disappearing network connections properly these days, so there is no need to mess around with startup order.
participants (5)
-
Joe Eaves
-
Maxime GAUDUIN
-
Paul Gideon Dann
-
Sébastien Luttringer
-
Thomas Bächler