On 02/20/2018 01:42 AM, Richard Laager wrote:
> I think you'd be better off either granting CAP_SYS_TIME to your
> container and running ntpd normally (only in the container), or running
> it normally from the host. If you're able to test the former, I'm happy
> to lift the
On 02/19/2018 05:44 AM, Daniel Baumann wrote:
> hrm, typo.. (s/locklock/lockclock/); but the result is the same, it
> doesn't compile (neither the debian package nor the upstream git snapshot).
It compiles fine for me. What error are you getting?
Also, I'd like to revisit what you're trying to
On 02/19/2018 11:37 AM, Daniel Baumann wrote:
> waf: error: no such option: --enable_locklock
hrm, typo.. (s/locklock/lockclock/); but the result is the same, it
doesn't compile (neither the debian package nor the upstream git snapshot).
Regards,
Daniel
Hi Richard,
On 02/19/2018 09:42 AM, Richard Laager wrote:
>> Try --enable_lockclock and a local refclock.
>
> Are you able to try this?
i've added that to debian/rules, but it fails with:
waf: error: no such option: --enable_locklock
i've tried with latest upstream git, no luck either.
Hal Murray wrote:
> That mode should be there. I haven't tested it.
>
> Try --enable_lockclock and a local refclock.
Are you able to try this?
It would involve rebuilding the package with the --enable-lockclock
option to `waf configure`. The "local" refclock is already built-in.
Even if it
On 02/19/2018 08:31 AM, Richard Laager wrote:
> If only for testing, what happens if you omit -u and its value?
then it happily runs.
> I'm not sure why ntp's ntpd wouldn't stop. The code is the same (note
> the exit(-1) call):
yes, i saw that too, yet there must be some difference somewhere
Hi,
On 02/19/2018 07:14 AM, Richard Laager wrote:
> To address this, I propose removing these two from ntp.service:
>
> ConditionVirtualization=!container
> ConditionCapability=CAP_SYS_TIME
>
> but leave them in ntp-wait.service.
makes sense, however, seems not enough (see below).
> If the
On 02/19/2018 01:14 AM, Daniel Baumann wrote:
> # /usr/sbin/ntpd -p /var/run/ntpd.pid -g -x -u 103:105 -ddd
...
> comparing to ntp, this looks almost the same, except that after the
> 'failed to drop root privs' ntp doesn't stop, whereas ntpsec does.
If only for testing, what happens if you omit
On 02/18/2018 11:24 AM, Daniel Baumann wrote:
> I'd like to run ntpsec as a daemon in a container. However, ntpsecs
> systemd units currently declare conflicts to be run in a container.
To address this, I propose removing these two from ntp.service:
ConditionVirtualization=!container
Package: ntpsec
Version: 1.0.0+dfsg1-1
Severity: normal
Hi,
I'd like to run ntpsec as a daemon in a container. However, ntpsecs
systemd units currently declare conflicts to be run in a container.
Second, the ntpsec default ntp configuration tries too hard to adjust
the local hardware clock. In
10 matches
Mail list logo
