On Thu, Mar 08, 2018 at 05:08:16PM +0100, Christian Ehrhardt wrote: > 1. the option would not be default on, so "normal" users/installations > would not be affected > 2. cases that want the fallback behavior, but are unable to probe/detect at > the time: > - so they can not decide to use normal -x > - also the environment might change on them withut reconfig > Both of the above would be solved by them dropping the new -x=fallback > option for their case.
Does that include an assumption that if the clock cannot be controlled, it's already synchronized by something else and if it can, it's a separate time namespace? > Our container folks will outline the CAP_SYS_TIME issue I mentioned before, > so really the best test for my suggested SYS_IsTimeAdjustable would be (on > top to what I have to check the Cap) a adjtime no-op. > I tried via adjtimex cmdline and thought maybe "adjtimex -s 0" (in C from > chrony eventually) would be a no-op check I'd think The sys_linux initialization code resets the singleshot offset, which could be used as an early check for adjtimex(). Ok, here are some suggestions for the implementation: - change all SYS_*_Initialise() functions to return 1 and SYS_Initialise() to check the return code (with a LOG_FATAL message if it is 0) - change reset_adjtime() and SYS_Linux_Initialise() to return 0 on failure - change SYS_Initialise() to handle the failure if clock_control is -1 and add (and document) -X option which sets clock_control to -1 in main.c -- 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.