On Wed, Apr 24, 2019 at 2:39 PM Theo de Raadt <dera...@openbsd.org> wrote:

> sven falempin <sven.falem...@gmail.com> 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 )

Reply via email to