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

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

....
> concept of a time namespace in the future. For most non-namespaced
> resources applications that are expected to run in user namespaces
> (systemd, lxc, etc.) follow the concept of "seek forgiveness, not
> permission" meaning one should usually check whether an operation is


That, for a program, sounds really really dangerous. "Opps, sorry I just
destroyed 20 years or work. You do have a backup don't you?"


> possible and if it is not move on or fallback to another more
> appropriate mode. Now, this is of course an application-by-application
> decision. Now, I think it would make sense for chrony to be a "seek
> forgiveness, not permission" application since a) it is expected to be
> run in user namespaces and b) there'll be a time-namespace. Actually a
> good friend of mine from Red Hat is looking into this. :)

I think planning on a kernel  implimentation that has just been thought of is also a
pretty dangerous proceedure. I must say I like "If it cannot do what it is
supposed to do, stop and issue an error message" philosophy much better.
Having that linked to an option to force some behaviour so that the decision
is entirely up to the user is better if really needed.

It sounds like this is all an effort to get around bad design for the
container or for some program. The effort should go there, rather than adding
features which could come back to bite you into chrony.
Every new feature introduces bugs. 
> Christian
>
> > > > Btw - for the reason above (haivng the cap, but not able to set time) is
> > > > there any way to adjtimex, but
> > >
> > > Check if adjtimex() works before chronyd is started? The adjtimex(8)
> > > utility could be used for that.
> > >
> > > > An additional default-off option to then in turn disable syncing the
> > > clock
> > > > would be my perfect solution.
> > > > Can we disable it so late, as I thought we detect the inability to do so
> > > > rather late?
> > > > That way people could opt-in to a "instead of the (now better) failure, I
> > > > want it to run on less accuracy in pure server mode"
> > > >
> > > > How about that?
> > >
> > > I'd rather keep it simple and avoid implementing an automatic fallback
> > > in chrony.
> > >
> > > --
> > > Miroslav Lichvar
> > >
> > > --
> > > To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with
> > > "unsubscribe" in the subject.
> > > For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the
> > > subject.
> > > Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.
> >
> >
> > --
> > Christian Ehrhardt
> > Software Engineer, Ubuntu Server
> > Canonical Ltd
>
> --
> To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
> For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
> Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.

--
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.