| 2020-03-31 10:28:26 |
Christian Ehrhardt |
description |
systemd[1]: Starting chrony, an NTP client/server...
chronyd-starter.sh[17458]: Warning: Missing cap_sys_time, syncing the system clock will fail |
We haven't released Focal yet, but we are in Beta freeze.
This fix is important and to help the release Team I'll add an SRU Teamplate which is a form/style everyone knows.
[Impact]
* capsh changed the output and chrony scripts used to parse that
* that failed parsing leads to detecting the lack of cap-sys_time ALWAYS
* due to that chrony in focal can't sync time at all, as always -x is
appended which is a critical impact and IMHO should make us accept this
fix asap.
[Test Case]
* install/upgrade chrony in an environment that can set time (bare metal,
VMs, but not containers)
Without the fix it will report:
$ systemctl status chrony
Mar 31 08:34:57 f-chrony systemd[1]: Starting chrony, an NTP client/server...
Mar 31 08:34:57 f-chrony chronyd-starter.sh[9108]: Warning: Missing cap_sys_time, syncing the system clock will fail
Mar 31 08:34:57 f-chrony chronyd-starter.sh[9108]: Adding -x as fallback disabling control of the system clock, see /usr/share/doc/chrony/README.container to override this behavior
* With the fix on those environments it will work again.
Mar 31 10:17:51 f-chrony systemd[1]: Starting chrony, an NTP client/server...
Mar 31 10:17:51 f-chrony chronyd[10780]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
Mar 31 10:17:51 f-chrony chronyd[10780]: Frequency -0.027 +/- 0.117
ppm read from /var/lib/chrony/chrony.drift
Mar 31 10:17:51 f-chrony chronyd[10780]: Loaded seccomp filter
Mar 31 10:17:51 f-chrony systemd[1]: Started chrony, an NTP client/server.
* One can also check the chrony commandline, in environments able to set the time it should NOT contain the "-x" argument
[Regression Potential]
* There would have been the risk of restarting the service on an upgrade
before the new capsh is around, but I've added a versioned dependency.
Other than that:
- on VMs/Bare-Metal since it is false-posiive today it can't regress
further and nothing else was changed
- on Containers if we made a mistake it would NOT detect as a lack of
cap_sys_time due to that chronyd there would start and fail trying to
sync the clock. That is the default upstream behavior - our addition
of a "try to run in containers" is only a helping hand to e.g. time
forwarders set up there like MAAS does.
Therefore overall no regression risk that should stop this upload IMHO.
[Other Info]
* the second case broken by capsh output, I'm glad the capability check
now become an explicit option to reduce the chance of this happening
again.
---
systemd[1]: Starting chrony, an NTP client/server...
chronyd-starter.sh[17458]: Warning: Missing cap_sys_time, syncing the system clock will fail |
|
