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.

Lonnie


> -- 
> 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.

Reply via email to