| Re: [chrony-users] Request: Add an optional timeout option for 'chronyd -q ...' |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, Nov 30, 2016 at 02:01:19PM -0600, Lonnie Abelbeck wrote:
> HI,
>
> We are in the process of moving from 'ntp' to 'chrony' for our open source project.
>
> In a matter of a few hours, I have made the conversion, including testing by booting without a network connection, restart chrony every 10 seconds for a 100+ times, etc .
That is a very good way to trigger rate limiting on the servers. :)
> What we would like is a "-t timeout" option to be used with "chronyd -q ..." just like sntp's -t option. I have seen cases where "chronyd -q ..." hangs without a timeout.
>
> The last thing we want to for chronyd to hang at boot time, and it can without such a timeout option, here are some logs...
>
> 2016-11-30T18:50:24Z chronyd version 2.4.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER -SECHASH +ASYNCDNS -IPV6 -DEBUG)
> 2016-11-30T18:50:24Z Initial frequency -17.442 ppm
> 2016-11-30T18:50:26Z Received KoD RATE from 138.68.46.177, burst sampling stopped
> (Hung for minutes or longer, a ^C was require to continue)
chronyd needs at least 3 samples to adjust the clock. So the time
chronyd -q will need depends on how early the server starts rate
limiting the responses or sending KoD RATE packets. If the first
response is KoD RATE, which disables the burst, and then all responses
are good, it will take about 7 minutes to get 3 good samples (assuming
default minpoll of 64 seconds).
> Does adding a "-t timeout" option to be used with "chronyd -q ..." sound reasonable ? We would probably use -t 8 (in seconds) for the upper bound.
So you would be ok with chronyd not setting the clock? Why does it
need to block the boot sequence then?
I think a -t option might make sense in some cases, but I'm wondering
if it rather should be a more general option to always exit after
specified number of seconds instead of changing the behaviour of the
-q/-Q option. I guess this could be useful with extremely long polling
intervals. On systems with very limited memory chronyd could be
periodically started for a short time with the -r option, and unlike
ntpdate and other simple clients it would still be able to correct the
frequency offset.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.