On Wed, Mar 7, 2018 at 3:43 PM, Miroslav Lichvar <mlich...@redhat.com>

> On Wed, Mar 07, 2018 at 01:51:31PM +0100, Christian Ehrhardt wrote:
> > In unprivileged containers even after e8096330 "sys_linux: don't keep
> > CAP_SYS_TIME with -x option" default installations
> > will still run without an explicit -x being set and therefore fail by
> > missing CAP_SYS_TIME.
> >
> > Usually users want services to "just work" which in a non-CAP_SYS_TIME
> > environment means that chrony will fulfil just the NTP serving task but
> > not the local time control.
> >
> > Therefore imply -x in those environments.
> I'm not sure about this.
> I can see that it would be convenient in some cases to have a service
> that automatically falls back to -x, but in the vast majority of cases
> I think chronyd is expected to control the clock and if that is not
> possible, it should fail.
> For example, if I had a docker image with chronyd configured as an NTP
> client and I forgot to give it the CAP_SYS_TIME capability, it would
> be much likely for me to miss the problem if it fell back to -x.
> There are some considerations that should be made before enabling -x.
> In order for chronyd to be a good NTP server, the system clock either
> needs to be free running (and all applications running on the system
> happy with an unsynchronized system clock), or it needs to be
> synchronized by another process and chronyd with -x is just serving
> the local time (chrony.conf includes the local directive, but no time
> sources are specified).
> There are other issues with running an NTP client/server in a
> container, e.g. network interfaces don't support SW/HW timestamping,
> which has an impact on accuracy.

I thought that having the server portion work by default would be very nice
to user.
But I agree that if time there is like "really bad" then it has to be an
explicit opt in by user/tool that sets it up.

So the question is, is this "so bad" that we should not fall back by
Or is this a minor degradation and the comfort for the NTP server component
to just work outweighs the concern.

> What do others think?

Absolutely, me as well.

P.S. if this will be a tradeoff we can't decide (but really only then) -
how about adding a new cmdline option to enable (or disable) this new
That would allow downstreams to decide if they want either or the other

> 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 Ltdh

Reply via email to