On Wed, 17.07.13 11:29, Miroslav Lichvar (mlichvar@xxxxxxxxxx) wrote: > On Tue, Jul 16, 2013 at 09:47:39PM +0200, Lennart Poettering wrote: > > On Tue, 16.07.13 21:10, Miroslav Lichvar (mlichvar@xxxxxxxxxx) wrote: > > > Possibly related question: Is there a way to start a daemon with > > > different options on restart than on start, something like > > > ExecRestart? > > > > No. And I am not convinced that that's a good idea to have. > > Is this one of the "never going to happen" things or could you be > convinced? One of the cases of: if we went down all other avenues, and if the patch is beautiful, and your usecase supersuper strong, then sure. But I don't see that really. > > > This would allow restarting chronyd with the -r option to load old > > > samples and speed up the initial synchronization. > > > > Hmm, this sounds like something to maybe just solve based on a simple > > time scheme? i.e. reuse if the old samples are not older than 1h or so? > > I don't think a time check would be reliable here. The samples should > be loaded only when they are still valid, i.e. nothing else has > touched the clock. It improves the initial response if used > correctly, but makes it much worse if used with invalid samples. > And chronyd can't know how good are the samples until it's too late. > > The safest approach is to use in only when the service is restarted. > It must not be used when someone stops the service, runs ntpdate and > starts chronyd again. > > An even better example might be the -R option, which tells chronyd to > not step the clock on start. If it was used on service restart, we > would be sure there are no time jumps when the chrony package is > upgraded. But for -R even more looking at the clock is actually the better choice and already what happens, no? I mean, the stepping is only done if the time difference is greater than some threshold. That sounds like a much better solution, since it always works. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
