On Wed, Mar 14, 2018 at 11:16:10AM +0100, Christian Ehrhardt wrote: > On Wed, Mar 14, 2018 at 11:01 AM, Miroslav Lichvar <mlich...@redhat.com> > wrote: > > At this time, I'd be interested in including only in the first one. We > > can reconsider the other two later if you are still interested. > > > > Worst case we at least improve the messaging which is better than nothing. > > That can be ok depending on what "later" means, what timeline are we > talking about for "later"? > In March is kind of ok, >=April would likely be too late for me.
I think this all needs more discussion and I would like to postpone it at least after 3.3, which will hopefully be released at the end of March. To me it feels like there is a bigger problem that needs to be solved first. Containers need more information about the system clock, which only the host can provide. If this can be fixed (I'm not sure how), maybe there will be a better solution for the problem that -X was intended to fix. > > The example unit file shouldn't change. > > > > Well, without dropping ConditionCapability=CAP_SYS_TIME it will never try > to use it. > No matter if one configures it for -x or the new -X - it will just not even > try while it would work inside the limits of -x/-X in those cases. The example unit file is intended for the typical use case, where starting chronyd in containers (with or without -x/-X) makes no sense. The thing that enables the -x/-X option should also remove the ConditionCapability. If you will go with the wrapper approach, you can modify the file in your downstream package. -- 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.
