| Re: [chrony-dev] [PATCH] main: imply -x if time can't be set |
[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]
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.
--
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 .
| Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |