On Tue, Mar 13, 2018 at 4:02 PM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> On Tue, Mar 13, 2018 at 2:50 PM, Miroslav Lichvar <mlich...@redhat.com>
> wrote:
>> On Tue, Mar 13, 2018 at 12:17:41PM +0100, Christian Ehrhardt wrote:
>> > The important part is the lack of knowledge of the target systems
>> > capabilities.
>> > They are:
>> > - not detectable by some install paths, for example
>> >   - install in VM with behavior A onto phys disk but reboot host into
>> said
>> > disk
>> >   - installing on a remote disk mounted chroot, which might be totally
>> > different when this runs.
>> >   - ...
>> > - Several tools/configs might add/remove capabilities from a system
>> later
>> > on in the lifecycle
>> > - Some move machines between places with different capabilities
>> Does any of this change the requirement on synchronization of the
>> system clock?
>> Something has to install and configure the chronyd service to run as
>> an NTP server on the system. (By default it's just a client.) What
>> does decide if -x/-X is added to the options?
> For above cases the example would be a tool that needs time
> synchronization, pulls in chrony but the tool wants to ensures it runs
> wherever it ends up (with clock sync if it can, but at least the NTP server
> part if it can't).
> There are even discussions ongoing if for Ubuntu we would want to default
> to -X in general (as default in a config file).
> > - ...
>> > The TL;DR of the "motivation" is: the inability to decide if using "-x"
>> is
>> > right or not (at any time).
>> I think the same applies to -X.
> No it's not.
> The users that started this with a Launchpad bug would always set -X for
> their case.
> They would never want to set "-x" or "", but "-X" would be just what they
> want.
> > With just "-x" available this leads to one of the following:
>> > A) So if one sets "-x" it will NEVER sync the clock even if the system
>> > would be capable to do so.
>> The system may be capable, but nothing requires the clock to be
>> synchronized, right? Otherwise it would make no sense to use any of
>> the -X/-x options.
> Partially correct, nothing "hard requires" the clock to be synced, but it
> is "preferred" to sync it if possible so setting -x would waste that.
> > BTW - in case it might be better to discuss interactive - I'm "cpaelzer"
>> on
>> > freednode IRC.
>> > If there is a common place chrony matters are usually discussed (other
>> than
>> > the ML) that would be nice to know - I haven't found a hint about it on
>> the
>> > web page.
>> I'm mlichvar on #ntp. People discuss chrony there occasionally.
> Thanks, will join there shortly to hopefully get our intentions fully
> clear in a discussion there.

In our discussions we came up with an alternate approach that I might code
I'll outline this in a following paragraph, but I must admit I really think
-X is much cleaner as it has:
- no service name confusion
- more clear messaging on Initialisation what failed
- the ability for those who want the "NTP serve in anyway, sync time if
able to" to opt into that

The new idea would be based on a secondary systemd service.
- If chrony.service fails it would trigger a fallback via OnFailure [1]
- a secondary service e.g. chrony-server-fallback.service that runs with -x
by default
=> So in a case where the "normal" client+server service fails the "NTP
server only" can take over.

Also the alternative would trigger the fallback for ANY cases to fail, not
just the very selective "if failed to adjust time".
I really think it is less transparent than providing -X for people to opt
in to if they want.
But it was good writing it up still to see it better - opinions are
welcome, but I'm still leaning heavily towards "begging you to accept -X."


> --
>> Miroslav Lichvar
>> --
>> To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
>> "unsubscribe" in the subject.
>> For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in
>> the subject.
>> Trouble?  Email listmas...@chrony.tuxfamily.org.
> --
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Reply via email to