On Fri, Mar 9, 2018 at 8:18 AM, Miroslav Lichvar <mlich...@redhat.com>
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.

Reply via email to