Re: [chrony-dev] [PATCH] main: imply -x if time can't be set

On Fri, Mar 9, 2018 at 8:18 AM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

On Thu, Mar 08, 2018 at 06:09:00PM +0100, Miroslav Lichvar wrote:
> On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote:
> > 1. the option would not be default on, so "normal" users/installations
> > would not be affected
> > 2. cases that want the fallback behavior, but are unable to probe/detect at
> > the time:
> > - so they can not decide to use normal -x
> > - also the environment might change on them withut reconfig
> > Both of the above would be solved by them dropping the new -x=fallback
> > option for their case.
>
> Does that include an assumption that if the clock cannot be
> controlled, it's already synchronized by something else and if it can,
> it's a separate time namespace?

From the little information I found about proposed time namespaces, it
looks like they would just have a fixed offset to the non-namespaced
time and wouldn't have an independent frequency, so couldn't be
controlled by chronyd anyway.

I still don't see the use case for the fallback. If applications
running in the container are ok with chronyd not controlling the
clock, why not always use -x there? At least it will be less likely to
hit the case where two things are trying to control the clock.

The use case IMHO is for anyone that wants to opt-in to a "just have ntp serving work at any quality" behavior.

That would fulfil the needs of the reporter of my bug at least - so there is a valid use case.

Setting -x for them breaks on two things:

1. for them it is much harder to check cap and adjtimex working on the target

2. a system as-is might be moved, so no static "-x or no -x" config will be correct

It moves with -x set to a place that could have good time -> wasting accuracy

it moves without -x set -> might fail after the move

So for them the -x=fallback is just what they'd need

Thanks for the suggestions on the last post, I'm travelling today so no patch for now.

I hope to submit a v2 to rekindle the discussion about something people can look at next week.