| 2020-04-01 14:06:32 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2020-04-02 06:16:13 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/381562 |
|
| 2020-04-02 06:16:45 |
Christian Ehrhardt |
chrony (Ubuntu): status |
New |
In Progress |
|
| 2020-04-02 06:17:17 |
Christian Ehrhardt |
summary |
chrony test 100-clockupdate flaky in autopkgtest |
autopkgtest identified fighting time services |
|
| 2020-04-02 06:26:05 |
Christian Ehrhardt |
description |
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 |
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
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 |
|
| 2020-04-02 06:26:37 |
Christian Ehrhardt |
description |
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
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 |
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
* 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 |
|
| 2020-04-03 09:00:05 |
Christian Ehrhardt |
chrony (Ubuntu): importance |
Undecided |
High |
|
| 2020-04-03 09:00:09 |
Christian Ehrhardt |
chrony (Ubuntu): importance |
High |
Critical |
|
| 2020-04-06 05:26:24 |
Christian Ehrhardt |
description |
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
* 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 |
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
[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 |
|
| 2020-04-06 10:56:53 |
Launchpad Janitor |
chrony (Ubuntu): status |
In Progress |
Fix Released |
|
