It seems to be racy/flaky and the comparison is on second 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.
Ha - my assumption was
x86 working on a retry as well now :-/
Due to that the package migrated.
I'm glad it worked as that matches what my 7 local retries all confirm.
But I'm slightly scared if this might randomly come back.
It might stay one of those "happened only on autopkgtest infrastructure" issues
:-/
If it
This bug was fixed in the package chrony - 3.5-6ubuntu2
---
chrony (3.5-6ubuntu2) focal; urgency=medium
* fix capsh usage in focal avoiding to always fall back to -x (LP: #1867036)
- d/control: add versioned dependency to libcap2-bin new enough to
support --has-p
-
Running in a autopkgtest-VM (x86):
- 2x all-proposed
- 1x just the new chrony from proposed
All these tests worked fine
At the same time I've prepped tests on s390x (KVM) and ppc64 (canonistack) -
with all proposed.
There all tests ran successfully on both architectures.
x86(1-3):
SUMMARY:
Ok, the following confirms what I have assumed about glibc.
The reset let glibc pass but now we are just as broken. I remember having a
discussion about that before, maybe now all changes are ready to be added.
revno: 4655
committer: Steve Langasek
branch nick: hints-ubuntu
timestamp: Mon
Liiking should have been Looking :-)
--
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:
Of course when things should be fast they are accompanied by a bunch of
test errors.
I'm seeing these two:
amd64 & s390x
autopkgtest [14:27:33]: test run_destructive_system_tests:
[---
100-clockupdate Testing update of system clock:
...
checking system clock
Fix uploaded, will need to be reviewed and approved by the release team
(beta freeze)
--
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
** 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
+
+ *
Testing with the PPA confirms the issue is fixes:
It now looks like this:
bare-metal/VMs:
ar 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
** Merge proposal linked:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/381424
--
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
libcap change was:
=>
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=588d0439cb6495b03f0ab9f213f0b6b339e7d4b7
That is in 2.32 and later.
Lets add a versioned dependency to ensure upgraders don't get awkward
issues (missing --has-p) on service restarts before the right things
Just as Rich reported (but here in full detail):
Old (eoan):
Current: =
Confirmed on a normal install in a VM:
ubuntu@f-chrony:~$ journalctl -u chrony
-- Logs begin at Mon 2020-03-30 13:21:33 UTC, end at Mon 2020-03-30 14:26:38
UTC. --
Mar 30 14:26:34 f-chrony systemd[1]: Starting chrony, an NTP client/server...
Mar 30 14:26:34 f-chrony chronyd-starter.sh[7534]:
Thanks Rich for that hint, I've seen this issue of the changed output
hit LXD and yes that might be the issue here.
If indeed that is a false positive it will add -x which isn't intended
for cases where it would be fine to run without (only wanted to too hard
isolation breaking chrony).
**
Looking into this, it seems the problem is that /usr/lib/systemd/scripts
/chronyd-starter.sh expects to be able to check for the cap_sys_time
capability by grepping the output of "capsh --print" for
"^Current.*cap_sys_time". However, in Focal the output of "capsh
--print" for a root process is
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: chrony (Ubuntu)
Status: New => Confirmed
--
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:
For me chrony 3.5-6ubuntu1 gets happier when I tell systemd to hand it
the CAP_SYS_TIME capability.
# cat /etc/systemd/system/chrony.service.d/cap_sys_time.conf
[Service]
AmbientCapabilities=CAP_SYS_TIME
#
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Confirmed on amd64 (vmware vm without docker, lxd, ...)
# systemctl restart chrony
# systemctl status chrony
● chrony.service - chrony, an NTP client/server
Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor
preset: enabled)
Active: active (running) since Fri
With SYNC_IN_CONTAINER="yes" in /etc/default/chrony it works.
$ timedatectl
Local time: Fri 2020-03-13 21:51:42 CET
Universal time: Fri 2020-03-13 20:51:42 UTC
RTC time: n/a
Time zone: Europe/Paris (CET, +0100)
System clock synchronized:
$ pscap -a | grep chrony
1 50749 _chrony chronyd net_bind_service, sys_time +
50749 50750 _chrony chronyd net_bind_service, sys_time +
** Changed in: chrony (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member
Hello,
no I'm not using -proposed.
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Focal Fossa (development branch)"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
Hi Cryolithe,
I know that glibc changed things in 2.31 but I thought that is in proposed
still.
I was working (I thought just for test/build issues) on an update in bug
1866753.
It does internal syscall filtering and that changed in glibc.
Out of that I already have PPA:
And it happened after a reboot, then maybe since the last kernel update.
--
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
Answer
** Changed in: chrony (Ubuntu)
Status: Incomplete => New
--
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
Hello, the version is :
||/ Name Version Architecture Description
+++-==---=
ii chrony 3.5-5ubuntu1 arm64Versatile implementation of the
Network Time Protocol
And yes, on bare
I can precise that it was working until recently, it doesn't work
anymore since about a week, after an "apt upgrade".
--
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 :
Hello Cryolithe and thanks for filing this bug report. In order to
understand if what you observe is actually a bug or the expected
behavior of chrony we need to know two things:
1. What is the exact version of the package you have installed?
2. Are you running Focal on bare metal, in a virtual
Tested on armv7l and aarch64.
--
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:
29 matches
Mail list logo
