Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

Le 13/03/2018 à 19:57, Christian Ehrhardt a écrit : > > > On Tue, Mar 13, 2018 at 5:54 PM, Bill Unruh > wrote: > > [17:25] * cpaelzer fails at explaining it seems > [17:25] if you deploy chrony to a random system > > > If

Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

On Wed, Mar 14, 2018 at 11:42 AM, Miroslav Lichvar wrote: > On Wed, Mar 14, 2018 at 11:16:10AM +0100, Christian Ehrhardt wrote: > > On Wed, Mar 14, 2018 at 11:01 AM, Miroslav Lichvar > > wrote: > > > At this time, I'd be interested in including only in

Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

Few more thoughts about this. On Tue, Mar 13, 2018 at 05:40:56PM +0100, Christian Ehrhardt wrote: > [17:28] We have two cases how this can run > [17:28] 1. if this runs on a Host that can set time, it has to > be in sync with what it serves time to - so it needs to set local time > [17:28] so

Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

On Wed, Mar 14, 2018 at 11:01 AM, Miroslav Lichvar wrote: > On Tue, Mar 13, 2018 at 10:45:56AM +0100, Chr?stian Ehrhardt wrote: > > doc/chronyd.adoc | 7 +++ > > examples/chronyd.service | 1 - > > main.c | 10 +++--- > > sys.c

Re: [chrony-dev] [PATCH v3] main: add -X to fall back if time is not adjustable

On Wed, Mar 14, 2018 at 11:16:10AM +0100, Christian Ehrhardt wrote: > On Wed, Mar 14, 2018 at 11:01 AM, Miroslav Lichvar > 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. > >

Re: [chrony-dev] [PATCH v4 0/3] chrony in environments unable to adjtime

Le 14/03/2018 à 15:05, Christian Ehrhardt a écrit : > There are several conditions which make running chrony in containers a pain > today and this series tries to provide means to handle that. > > What is the real use case of Chrony in a container ? Why do you want to do that ? > Until time

[chrony-dev] [GIT] chrony/chrony.git branch master updated. 3.2-68-gd34e611

This is an automated email from git. It was generated because a ref change was pushed to the "chrony/chrony.git" repository. The branch, master has been updated via d34e611ec8f12ca26bd79348a70b1c098460e28f (commit) via 02098ed830815e1856e92b7328e2630a62fcdad9 (commit) via

[chrony-dev] [PATCH v4 0/3] chrony in environments unable to adjtime

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

[chrony-dev] [PATCH v4 2/3] sys: rework initialisation to return a value

This ensures any failure to initialize the clock driver will eventually end in a unified clear statement that it failed to do so instead of a random mix or EPerm or other issues that happened on init. The potential root causes (e.g. said Eperm) is still reported as warning. Furthermore this

[chrony-dev] [PATCH v4 3/3] main: add -X to fall back if time is not adjustable

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. In some use cases users want the NTP server service to "just work" which in a

Re: [chrony-dev] [PATCH v4 2/3] sys: rework initialisation to return a value

On Wed, Mar 14, 2018 at 03:05:30PM +0100, Christian Ehrhardt wrote: > This ensures any failure to initialize the clock driver > will eventually end in a unified clear statement that it failed to do > so instead of a random mix or EPerm or other issues that happened on > init. > > The potential

[chrony-dev] [PATCH v4 1/3] sys_linux: report if CAP_SYS_TIME is not present

Instead of having adjtimex just fail with a permission issue improve the error messaging by warning for the lack of CAP_SYS_TIME on SYS_Linux_Initialise. Message will look like (instead of only the latter message): CAP_SYS_TIME not present adjtimex(0x8001) failed : Operation not permitted

Re: [chrony-dev] [PATCH v4 1/3] sys_linux: report if CAP_SYS_TIME is not present

On Wed, Mar 14, 2018 at 3:32 PM, Miroslav Lichvar wrote: > On Wed, Mar 14, 2018 at 03:05:29PM +0100, Christian Ehrhardt wrote: > > Instead of having adjtimex just fail with a permission issue > > improve the error messaging by warning for the lack of > > CAP_SYS_TIME on