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 clock is not being set by ntpd, ntpwait is useless.
jftr, i'm running ntp on the container server (host system) to adjust
the hardware clock, and intend to run ntpsec (without adjusting the
harware clock) in the container as the network service for other machines.
this works with ntp in the container out of the box, but not quite yet
with ntpsec.
> Can you explain what you mean by "tries too hard"?
this is what i get from starting ntpd manually
# /usr/sbin/ntpd -p /var/run/ntpd.pid -g -x -u 103:105 -ddd
02-19T08:07:58 ntpd[6234]: INIT: ntpd ntpsec-1.0.0+1
2017-10-09T23:52:12-0400: Starting
02-19T08:07:58 ntpd[6234]: INIT: Command line: /usr/sbin/ntpd -p
/var/run/ntpd.pid -g -x -u 103:105 -ddddd
02-19T08:07:58 ntpd[6234]: PROTO: precision = 0.170 usec (-22)
02-19T08:07:58 ntpd[6234]: INIT: mlockall() failed: not locking into RAM
02-19T08:07:58 ntpd[6234]: CONFIG: readconfig: parsing file: /etc/ntp.conf
02-19T08:07:58 ntpd[6234]: CLOCK: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
02-19T08:07:58 ntpd[6234]: CLOCK: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): loaded,
expire=2018-12-28T00:00Z last=2017-01-01T00:00Z ofs=37
02-19T08:07:58 ntpd[6234]: INIT: Using SO_TIMESTAMPNS
02-19T08:07:58 ntpd[6234]: IO: Listen and drop on 0 v6wildcard [::]:123
02-19T08:07:58 ntpd[6234]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123
02-19T08:07:58 ntpd[6234]: IO: Listen normally on 2 lo 127.0.0.1:123
02-19T08:07:58 ntpd[6234]: IO: Listen normally on 3 eno1 147.87.226.210:123
02-19T08:07:58 ntpd[6234]: IO: Listen normally on 4 lo [::1]:123
02-19T08:07:58 ntpd[6234]: IO: Listen normally on 5 eno1
[fe80::703b:efff:fece:88da%2]:123
02-19T08:07:58 ntpd[6234]: IO: Listening on routing socket on fd #22 for
interface updates
02-19T08:07:58 ntpd[6234]: CLOCK: start_kern_loop: ntpd/ntp_loopfilter.c
line 1127: ntp_adjtime: Operation not permitted
02-19T08:07:58 ntpd[6234]: CLOCK: set_freq: ntpd/ntp_loopfilter.c line
1090: ntp_adjtime: Operation not permitted
02-19T08:07:58 ntpd[6234]: INIT: cap_set_proc() failed to drop root
privs: Operation not permitted
#
comparing to ntp, this looks almost the same, except that after the
'failed to drop root privs' ntp doesn't stop, whereas ntpsec does.
> Can you clarify how the ntp package is different from ntpsec in this
> regard, other than the systemd unit changes discussed above?
i don't know, i looked a bit at the code but didn't see any obvious
differences in ntp_sandbox.c (ntpsec) compared to ntpd.c (ntp).
> I'm not aware of any option to tell ntpd to NOT sync the local clock.
me neither, but it would be nice to have one for this usecase. with ntp,
eventhough running it in a container works, it fills up the log
uselessly with 'adjtime operation not permitted'-sort-of lines. would be
nice if ntpsec could have an option to avoid this in the first place.
Regards,
Daniel
