Talking about time (ntpd -s)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Talking about time (ntpd -s)

sven falempin
Dear Tech reader,

NTPD -S is useful, when a device is in storage for a while the clock is in
disarray.
But this assume the network exists, the fixed 15 seconds timeout makes
sense,
nevertheless it could be too long or too short.

https://pastebin.com/gmNGpXLq

Also NTPD just log out the failure after 15 seconds, not informing a script
that time is probably wrong.

https://pastebin.com/z0eVrvgG

Alast why not just wait for something to respond and then set time ??
This (bit ugly) diff reveals some dead code in ntpd

https://pastebin.com/9PwqBDHz

Is there another way to bootstrap time correctly ?

Best
Reply | Threaded
Open this post in threaded view
|

Re: Talking about time (ntpd -s)

Chris Cappuccio
sven falempin [[hidden email]] wrote:
>
> Alast why not just wait for something to respond and then set time ??
> This (bit ugly) diff reveals some dead code in ntpd
>
> https://pastebin.com/9PwqBDHz
>
> Is there another way to bootstrap time correctly ?
>

ntpd will wait under normal invocation, but -s jumps the system time and
ntpd is only given the limited amount of time for this to happen. The system
does not want to jump to a new time once other daemons are started. That's
why the behavior is the way it is now. If you know you have an interface
that takes a long time to come up for some reason, you can add an appropriate
'sleep' statement in the hostname.if file, or even a script that takes on
a more complicated set of actions before allowing the system to move forward.

Reply | Threaded
Open this post in threaded view
|

Re: Talking about time (ntpd -s)

Theo de Raadt-2
In reply to this post by sven falempin
sven falempin <[hidden email]> wrote:

> Dear Tech reader,
>
> NTPD -S is useful, when a device is in storage for a while the clock is in
> disarray.
> But this assume the network exists, the fixed 15 seconds timeout makes
> sense,
> nevertheless it could be too long or too short.
>
> https://pastebin.com/gmNGpXLq
>
> Also NTPD just log out the failure after 15 seconds, not informing a script
> that time is probably wrong.
>
> https://pastebin.com/z0eVrvgG
>
> Alast why not just wait for something to respond and then set time ??
> This (bit ugly) diff reveals some dead code in ntpd
>
> https://pastebin.com/9PwqBDHz
>
> Is there another way to bootstrap time correctly ?

No. It is a crappy workaround.

I have schemed about a better method, but it is quite complicated
and hasn't been written.

Reply | Threaded
Open this post in threaded view
|

Re: Talking about time (ntpd -s)

sven falempin
On Wed, Apr 24, 2019 at 2:39 PM Theo de Raadt <[hidden email]> wrote:

> sven falempin <[hidden email]> wrote:
>
> > Dear Tech reader,
> >
> > NTPD -S is useful, when a device is in storage for a while the clock is
> in
> > disarray.
> > But this assume the network exists, the fixed 15 seconds timeout makes
> > sense,
> > nevertheless it could be too long or too short.
> >
> > https://pastebin.com/gmNGpXLq
> >
> > Also NTPD just log out the failure after 15 seconds, not informing a
> script
> > that time is probably wrong.
> >
> > https://pastebin.com/z0eVrvgG
> >
> > Alast why not just wait for something to respond and then set time ??
> > This (bit ugly) diff reveals some dead code in ntpd
> >
> > https://pastebin.com/9PwqBDHz
> >
> > Is there another way to bootstrap time correctly ?
>
> No. It is a crappy workaround.
>
> I have schemed about a better method, but it is quite complicated
> and hasn't been written.
>

[ or even a script that takes on
a more complicated set of actions before allowing the system to move
forward]


The only way is to check the log files for the messages, which is not so
easy to do correctly
in a bunch of script file.

Currently I wait 'internet' to be ready before starting ntpd, but then my
system MAY wonder why some
services started in a another space/time ( well another time only ).

So I am open to any suggestion to have a better way.

currently the patch https://pastebin.com/z0eVrvgG that change the exit code
in case timeout is reach
is the less ugly IMHO, maybe just let the daemon(1,0) call and print
something on STDERR or even STDOUT
so a script file knows it s wrong without looking for log ( which are time
based ! )

Best.

PS: ( can we remove the == -1 that does not exist, or is it a return error
in the called function  https://pastebin.com/9PwqBDHz )