FYI: Merge of 3.6-9 uploaded to Groovy ** Description changed:
[Impact] - * Chrony can't start on platorms that map gettimeofday to - clock_gettime64() + * Chrony can't start on platforms that map gettimeofday to + clock_gettime64() - * This is due to syscall filtering being correct on some but generic - enough to cover all areas. + * This is due to syscall filtering being correct on some but generic + enough to cover all areas. - * Vincent proposes a patch for it upstream and we intent to backport that - to Focal + * Vincent proposes a patch for it upstream that was accepted and this is + the backport of that to Focal [Test Case] - * Run chrony in >=20.04 on a platform that uses clock_gettime64 - * See a "Bad system call" when chrony starts - * With the fix that issue should be gone and chrony start fine + * Run chrony in >=20.04 on a platform that uses clock_gettime64 on 32 bit + An example would be an armhf RasbPi + * When chrony starts it will trigger "Bad system call" and fail + * With the fix that issue should be gone and chrony start fine [Regression Potential] - * We already allow the "other" gettimeofday and allowing this one as well - should not be a security issue. It is only a get function anyway. + * We already allow the "other" gettimeofday and allowing this one as well + should not be a security issue. It is only a get function anyway. + Usually opening up apparmor or seccomp filters doesn't cause regressions + (in comparison to removing permissions). Still the place to look for + regressions is behavior in regard to system calls - e.g. bad code could + lead to blocking other calls now which would be a real regression. [Other Info] - - * Until then a workaround is to disable syscall filtering - sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony + * Until then a workaround is to disable syscall filtering - * I have not yet fully tracked down which HW/Kernel/libc will trigger - this, to know this would help the later verification. + sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony + + * I have not yet fully tracked down which HW/Kernel/libc will trigger + this, to know this would help the later verification. --- This system fully updated 20.04 and is all default except for user password and keyboard layout. Package version is 3.5-6ubuntu6 Expected chronyd to start after install Install went OK, systemd-timesyncd was disabled and removed as expected, chrony.service was created as expected but chrony.service failed to come up. Journalctl -xe reports chrony.service entered the 'failed' state with result 'protocol' On a seperate attempt, on different storage, I tried forcing systemd- timesyncd off in case that was the issue and messing with apparmor but got nowhere. So I decided bring up a fresh install and file a bug report from there. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: chrony 3.5-6ubuntu6 ProcVersionSignature: Ubuntu 5.4.0-1008.8-raspi 5.4.29 Uname: Linux 5.4.0-1008-raspi armv7l ApportVersion: 2.20.11-0ubuntu27 Architecture: armhf CasperMD5CheckResult: skip Date: Mon May 11 12:35:41 2020 ProcEnviron: TERM=linux PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: chrony UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1878005 Title: Chrony crashes on install from raspberry pi 2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
