On Thu, Mar 08, 2018 at 03:15:36PM +0100, Christian Ehrhardt wrote: > On Thu, Mar 8, 2018 at 1:49 PM, Miroslav Lichvar <mlich...@redhat.com> > > 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-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.