There are several conditions which make running chrony in containers a pain today and this series tries to provide means to handle that.
Motivations: - Using ntpd in it's default config in a container caused it to complain in syslog about the inability to control the time while at the same time still providing a (not great but working) NTP server portion. This isn't possible anymore, unless the user sets -x AND drops the Condition on CAP_SYS_TIME in the service. - Some users would be able to change the config. But often those are mass deployments and it is unclear at the time of install (some might even change characteristics later in their lifecycle) if a given target system should get -x or not. But those users would want ONE (1) config that syncs the system clock if it can do so (not -x), but at the same time not fail if it can't (In those setups the Host keeps the system clock in sync, so it is not mutually exclusive to be "a requirement somewhere" but "not in other places" from their POV). - Because of the way user namespaces work each container using them starts of with a full capability set including CAP_SYS_TIME. However, the adjtimex syscall will still fail since the CAP_SYS_TIME capability check is performed against the initial user namespace of the host and container will *not* have this capability in the host's user namespaces. (See "Capabilities" in [1] for more complex details.) Without a fix this will let the service run by default (CAP_SYS_TIME is present in the users namespace) but then cause it to fail. This has unwanted consequences such as causing the default config to fail instantly. A very serious problem caused by this is that package upgrades which require service restarts to fail. Until time namespaces are implemented an appropriate and helpful solution to this problem is to adapt the default config that enables chrony to intelligently handle such scenarios. This series tries to enable this. Note: A totally different approach to this might be to break chronyd from being a "NTP client/server" service into a more independent entity of a client and a server. That would allow the server to run mostly anywhere, while the client portion obviously only makes sense where it can adjust time. But due to the fact that currently those are tightly coupled and need each other in the code that solution isn't anywhere close either. [1]: http://man7.org/linux/man-pages/man7/user_namespaces.7.html Christian Ehrhardt (3): sys_linux: report if CAP_SYS_TIME is not present sys: rework initialisation to return a value main: add -X to fall back if time is not adjustable doc/chronyd.adoc | 8 ++++++++ main.c | 5 ++++- sys.c | 22 ++++++++++++++++++---- sys_linux.c | 32 +++++++++++++++++++++++--------- sys_linux.h | 2 +- sys_macosx.c | 8 ++++---- sys_macosx.h | 2 +- sys_netbsd.c | 8 ++++---- sys_netbsd.h | 2 +- sys_solaris.c | 6 +++--- sys_solaris.h | 2 +- sys_timex.c | 39 +++++++++++++++++++++++++++------------ sys_timex.h | 16 ++++++++-------- 13 files changed, 103 insertions(+), 49 deletions(-) -- 2.7.4 -- 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.