On Dec 1, 2016, at 6:47 AM, Miroslav Lichvar <mlich...@redhat.com> wrote:
> On Thu, Dec 01, 2016 at 06:30:22AM -0600, Lonnie Abelbeck wrote:
>> Certainly, If a cron job was used to periodically call chronyd instead of
>> ntpdate, a "-t timeout_secs" option would be quite useful to make sure a
>> stuck/delayed chronyd would not prevent later chronyd's from running.
> I'd not recommend using a cron job, but rather something with random
> sleeps between the starts, so multiple clients are not sending
> requests at the same time. If you wanted it to correct frequency, it
> would have to be without the -q option as it can only step the clock
> without any adjustment of the frequency.
OK, thanks for the insight.
>> Just to be clear, I would suggest chronyd should not return 0 if the timeout
>> was reached and exited.
> How about returning 0 if the clock was in a synchronised state (the
> reference was updated at least once) and 1 if not? With -q that would
> be 0 only if the clock was stepped.
Yes, that would work for our situation.
For example using "chronyd -q -u ntp -t 10", if after 5 seconds the clock was
in a synchronized state, it steps the clock and exits 0. Alternatively if
after 10 seconds the clock was not yet in a synchronized state, it would exit
with a non-zero (timeout) return.
> Miroslav Lichvar
To unsubscribe email chrony-users-requ...@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-requ...@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email listmas...@chrony.tuxfamily.org.