On Thu, Mar 08, 2018 at 06:09:00PM +0100, Miroslav Lichvar wrote: > 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?
>From the little information I found about proposed time namespaces, it looks like they would just have a fixed offset to the non-namespaced time and wouldn't have an independent frequency, so couldn't be controlled by chronyd anyway. I still don't see the use case for the fallback. If applications running in the container are ok with chronyd not controlling the clock, why not always use -x there? At least it will be less likely to hit the case where two things are trying to control the clock. -- 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.
