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

On Thu, Mar 8, 2018 at 3:52 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:

On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote:
> On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar <mlichvar@xxxxxxxxxx>
> > But this is what users expect in most cases, right? If an NTP
> > client/server is installed and enabled in a container, it's usually
> > not intended, e.g. it was installed as a dependency of another
> > package.
> >
>
> The people concerned on the link Launchpad bug for example want to serve
> time.

If they have no other option how to do that, then it's ok. The number
of such users is (hopefully) very small.

> Hmm if it wouldn't sound as awkward I'd actually say you'd want to split
> the client & server services.

The client and server are tightly coupled. Some information need to be
exchanged between them for each response of the server.

> I agree that you'd want to reach time-sync target only after you sync - btw
> what does systemd-timesyncd in that case?

With timesyncd the time-sync target has almost no meaning. It's
reached as soon as the system time is compared with (and possibly
restored from) a timestamp saved in a file from previous boot. It does
not wait for any responses from NTP servers and the clock will be
stepped after the target is reached. As I understand it, it was done
this way to avoid delaying the boot.

> You mean as the container is not able to steer the clock it's
> own time-sync.target should actually be that of its host?

Yes, I think that would be nice if it was possible.

> Just as a heads up, due to the crazy world of capabilities some containers
> will soon expose CAP_SYS_TIME since it is correct to have the cap for their
> space.
> But when you actually adjtimex it will fail as it will eventually apply the
> hosts caps to it and that you don't have.
> This comes at the additional WTF (for me) that checking for CAP_SYS_TIME
> has effectively lost almost all its meaning :-/

Interesting. Is this described anywhere?

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

I understand the POV, but without even a default-off function for it I'm kind of forced to wrap a round it to be able to support the use-case in some way at least.

In general such a wrapper is inherently always slightly behind as not all downstreams share it, and I'd much more prefer coding something up that we share..

If that is a pre-nack to a patch adding a "-Please-fall-back-if-failing" then I don't have to waste the time writing it.

So is there a chance at all to add such a switch in your opinion?

--
Miroslav Lichvar

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

Christian Ehrhardt

Software Engineer, Ubuntu Server

Canonical Ltd