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. What do others think? -- 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.