** Description changed: + This SRU Template is meant to help the release team accepting this into + focal before release. + + [Impact] + + * 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 + + [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 + 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
** Description changed: This SRU Template is meant to help the release team accepting this into focal before release. [Impact] - * 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. + * 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) + 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 + * 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 [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. + * 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 + + * 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
