# ntpd initial time set failure...any way to prevent this?

## tld

On my mythtv backend system, I'd running net-misc/openntpd-6.0_p1 and I'm using the default NTP servers:

```
servers 0.gentoo.pool.ntp.org

servers 1.gentoo.pool.ntp.org

servers 2.gentoo.pool.ntp.org

servers 3.gentoo.pool.ntp.org
```

In my /etc/conf.d/ntpd I have this:

```
NTPD_OPTS="-s"
```

...to initially set the time on startup. After a reboot yesterday my time ended up 3 minutes off. It stayed that way, I'm assuming, because the running ntpd won't make adjustments that large(?), which is precisely why I use that "-s". This screwed up all my recordings from yesterday. I traced the issue to this, which I discovered in /var/log/syslog:

```
Nov 21 10:45:57 mythback ntpd[1571]: no reply received in time, skipping initial time setting
```

So apparently that took too long preventing the initial time adjust. I have to think that maybe that was just a glitch with those NTP servers(?) as they're clearly working. I just fixed that using "ntpd -d -s".

Is there ANY way to guard against this short of making sure the time is right after a reboot? I don't see any sort of timeout setting, and "man ntpd" says this in regard to the -s option:

```
ntpd will stay in the foreground for up to 15 seconds waiting for one of the configured NTP servers to reply.
```

Not happy with that one.

Tom

----------

## Ionen

I don't really know much about opentpd since I use ntp.org's ntpd (with -g option to allow large time changes), maybe it would work better for you. Also if you have a reliable LAN machine that's always up you could have it run a ntpd server to sync with (that's what I do, and it's the only one that will pool remote ntp servers if it's up rather than every machines on the network doing it, will provide a baseline should internet or other ntp servers be down if a machine is booted way off).

----------

## freke

ntpd comes with ntp-client (ntpdate) which is cabable of making big adjustments to the clock.

https://wiki.gentoo.org/wiki/Ntp

and ntpdate has a timeout option - https://linux.die.net/man/8/ntpdate

I've always had ntp-client start before ntpd on my computers to make the big adjustment if needed before starting ntpd (ntp-client is a onetime adjustment).

EDIT:

oops - didn't notice - openntpd, don't know about that :/

Is dns available when ntpd tries to start - i've had that problem?

----------

## tld

Thanks for the replies!...yea, DNS certainly should be available at that time. Also note that this usually doesn't happen but it did in this case, and I'm pretty sure it happened to me another time way back.

I actually used to use net-misc/ntp way back and for the life of me I have no idea why I switched. I though I recall that having to do with recommendations because of security concerns, but I can't find anything to that affect. Frankly there are a LOT of things I don't like about opennptd. For example:

The only means of manually setting the date even if dramatic changes are needed is to do what I have here. That is to start the service with -s. However that means that you CANNOT specify a different server for this purpose as compared to what you have in your config. For that reason I had to abandon using my mythtv backend as an NTP server for the frontend, because any time I needed to reboot both, openntp would consider the backend NTP server as not synced and the frontend wouldn't adjust. With net-misc/ntp I could configure ntpclient to use an internet ntp server for that purpose.

Maybe I'll switch back. I've always been bit annoyed with many aspects of openntpd frankly.

Tom

----------

## Ionen

net-misc/ntp is still getting updates which I'd assume is taking care of security issues if any (last stable release in March 2019). openntpd is still getting active development, but the last actual release was in October 2017 (the gentoo stable release is from 2016), not sure what's the status of this.

1-time boot-time checks is just not something that can be fully relied on either way, something may always be unavailable for one reason or another (being over LAN rather than remote at least helps but even then).

----------

## tld

I found some notes I had from back when I switched, and now I'm recalling more about this, but I'm a bit confused. Didn't the ntp project switch from the ntpdate program to sntp? I'm sure that was the case. Did ntpdate come back or something. I recall that sntp program was really confusing.

EDIT: Found this: https://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

It sounds like ntpdate is still in use after all this time though(?). Confusing.

Tom

----------

## tld

I've found some old posts and now I recall why I switched from ntp to openntpd. When I used net-misc/ntp I was using the sntp program for ntp-client, and was having occasional failures:

https://forums.gentoo.org/viewtopic-t-987724.html

However later I discovered that this was simply because I was attempting to sync my MythTV frontend to the backend computer, which would always fail if I'd recently rebooted the backend. This is because the backend was considered to be not synced, but the sntp program wasn't giving be any meaningful errors to indicate as much. See the last post here:

https://forums.gentoo.org/viewtopic-t-1008332-start-0.html

So arguably my reasons for switching really don't apply. That brings me back to my question about the sntp program vs ntpdate: *freke wrote:*   

> and ntpdate has a timeout option - https://linux.die.net/man/8/ntpdate

 Yes it does, and unlike it's sntp replacement, it actually makes sense. See the top of the first link above where I describe the almost unbelievably screwed up behavior of the sntp's -t option...almost beyond description.

Are those of you who use net-misc/ntp still configuring /etc/conf.d/ntp-client to use ntpdate and not sntp...despite the fact that ntpdate is theoretically deprecated? I'd actually like to switch back to net-misc/ntp, but that sntp program is a mess.

Tom

----------

## tld

Ultimately I've pretty much decided to stick with openntpd, especially after re-reading the things I ran into with sntp. As noted by Ionen, those boot time checks really can't be fully relied on regardless. It would be nice if the openntpd ntpd offered some timeout option for it's -s option. What is nice however is that, in the rare case where the time set fails, given that openntpd handles this in the daemon executable itself, fixing it is just a matter of restarting the service.

In the process of looking into this I found a nice bash command to check the current UTC from nist.gov that can be compared to "date -u":

```
cat </dev/tcp/time.nist.gov/13

58812 19-11-25 17:53:34 00 0 0 537.5 UTC(NIST) *
```

Tom

----------

## Ant P.

If you want an ntpd that just works, use chrony.

----------

## tld

 *Ant P. wrote:*   

> If you want an ntpd that just works, use chrony.

 Interesting...never even looked into that. The makestep directive looks interesting. Thanks!

----------

