** Description changed: + 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
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1867036 Title: Focal Fossa : chronyd unable to sync system clock To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1867036/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
