On Thursday, 24 August 2017 13:48:59 BST Terry Coles wrote:
> On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote:
> > ntp-wait(1) might be of interest: "This can be useful at boot time, to
> > delay the boot sequence until after ntpd -g has set the time".
>
> That is definitely of interest. If all else fails, then this could ensure
> that the clocks are synced before we try to run our software.
>
> However, the man page isn't very helpful with respect to when to launch it
> and where from. Since there isn't much point in delaying the start of the
> system until NTP itself has started, then I'm assuming that I could put it
> into rc.local, except that this file has the following comment in it:
>
> # This script is executed at the end of each multiuser runlevel.
>
> If it waits until the end of the runlevel, is that too late? Presumably, as
> long as further processing is delayed before we launch our software from
> .bashrc, we should be OK.
Ralph,
Well I tried it in rc.local and it works. It is an interesting experience,
because although it does hold up further booting until sync occurs, messages
continue to arrive from the boot process for a short time. I assume that this
is upstart in action, eg the residual messages come from boot activities
triggered by upstart before the command is executed, but which hadn't finished.
Anyway, the system then sits there doing next to nothing until the clock syncs
(you get a rather abrupt OK) and then our software starts immediately after.
I'd still like to know if there is a solution to the 10 minutes of KoDs, but
this will work and it isn't as if we are trying to control something that
needs microsecond response times.
Thanks for your help.
--
Terry Coles
--
Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
