The "other bug" is bug 1849156 will fix the concurrent running services.
I have subscribed on that other bug and asked rbalint to speak up if he expect it to not land in time for 20.04. On our side I'll upload the chrony fix, but reduced to just the test fixes. Those fixes are also already merged in Debian, so we can drop that Delta early in 20.10. ** Description changed: This SRU Template is meant to help the release team accepting this into focal before release. [Impact] + + Important: + The fix to avoid the services running concurrently moved + to bug 1849156 - this upload will only fix the test issues now. + I'll keep the test steps below as I'll want to test them with + the new systemd-timesyncd then. * Over the years there were multiple approaches to adapt different time service like ntp/chrony/systemd-timesyncd to work together. The recent Debian changes (3.5-6) fixed a certain type of issues of the former solution (conflicts) but opened another issue after install until reboot where now multiple service are active. Overall this: * Fix autopkgtests to not have chrony installed (fighting with the chrony service started by the tests) * Fix autopkgtests to disable systemd-timesyncd to not fight over the clock * Reload systemd-timesyncd after chrony install to pick up the drop in config placed by chrony * Adding a new test that ensures this is detected earlier in the future in case it reoccurs (again) [Test Case] * Install chrony, the state should be: - chrony running - systemd-timesyncd inactive => That should persist over reboots => In Ubuntu that even applies to containers - * Check new (and old) autopkgtest results + * Check new (and old) autopkgtest results [Regression Potential] * I don't think it is an issue , but I could see potential regressions in the restart of systemctl-timesyncd if people made customizations to it. Therefore we ignore the RC to not break chrony install - but it would be "please fix your config" as usual. Also important is that this would not be different to the situation these users would have had after a reboot. [Other Info] * n/a ---- FYI Separated from bug 1867036 It seems to be racy/flaky. It uses a comparison on "seconds" granularity. I was adding debug to check the values it fails on. It was somewhat reproducible in the bileto ticket (again autopkgtest infrastructure). Therefore I inserted some debug code and re-ran it there. Our test environment is too fast (sometimes) and hence the flakyness: checking chronyc output OK DEBUG before 1585747433 DEBUG before 1585747433 checking system clock BAD That is checked with "lt" and here the results are ==. I'll need to discuss if there is a strict reason for these to be non-equal. Otherwise the fix might be as easy as using "-le" instead -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1870144 Title: autopkgtest identified fighting time services To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1870144/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
