Chrony crashes on install from raspberry pi 2

Hi Jason,

Could you please show us the output of 'systemctl status chrony.service'?

See attached file for systemctl status output

Status changed to 'Confirmed' because the bug affects multiple users.

Same problem. Chrony starts without problems using "chronyd -d -d" as root.

From the log:
chrony.service: New main PID 1224 does not exist or is a zombie.
chrony.service: Failed with result 'protocol'.

I've had focal's chrony running on Pi3 and Pi4 systems without trouble - I wonder what that is about.

The "protocol" exit is seen a few times in regard to stricter PID handling, for example:
- https://unix.stackexchange.com/questions/493187/systemd-under-ubuntu-18-04-1-fails-with-failed-to-create-user-slice-serv
- https://github.com/systemd/systemd/issues/8085

Chrony sets:
PIDFile=/run/chronyd.pid

And on a normal system that is fine - the pidfile content matches the daemon.

But in your log this detection seems to go wrong as seen on "New main PID 1224 does not exist or is a zombie."

The start wrapper itself worked fine it seems:
ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCESS)
So it seems to have died later.

@Jason - in the error case could you on top of
  $ systemctl status chrony
also run the following:
 $ cat /run/chronyd.pid
 $ ps axlf | grep $(cat /run/chronyd.pid)
 $ ps axlf | grep chrony

And attach that output as well - just so we can see if there is a pid left running that hangs and/or if it is fully dead.

Also we might want to check directly if and why the service dies.
So if above no process is running, pelase do as root:
  $ source /etc/default/chrony
  $ /usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS
  $ echo $?
  $ ps axlf | grep chrony

And report that as well.

root@dc2:/etc/chrony# systemctl status chrony
● chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
     Active: failed (Result: protocol) since Wed 2020-05-13 15:07:23 CEST; 21s ago
       Docs: man:chronyd(8)
             man:chronyc(1)
             man:chrony.conf(5)
    Process: 15177 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS (code=exited, status=0/SUCCESS)
    Process: 15186 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (code=exited, status=0/SUCCESS)

Mai 13 15:07:22 dc2 systemd[1]: Starting chrony, an NTP client/server...
Mai 13 15:07:22 dc2 chronyd[15182]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS >
Mai 13 15:07:22 dc2 chronyd[15182]: Frequency -2.286 +/- 1.012 ppm read from /var/lib/chrony/chrony.drift
Mai 13 15:07:23 dc2 systemd[1]: chrony.service: New main PID 15182 does not exist or is a zombie.
Mai 13 15:07:23 dc2 systemd[1]: chrony.service: Failed with result 'protocol'.
Mai 13 15:07:23 dc2 systemd[1]: Failed to start chrony, an NTP client/server.

root@dc2:/etc/chrony# cat /run/chronyd.pid
cat: /run/chronyd.pid: Datei oder Verzeichnis nicht gefunden

[Skipped ps axlf | grep $(cat /run/chronyd.pid)]

root@dc2:/etc/chrony# ps axlf | grep chrony
0 0 15232 2599 20 0 6788 600 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony

root@dc2:/etc/chrony# source /etc/default/chrony
root@dc2:/etc/chrony# /usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS
root@dc2:/etc/chrony# echo $?
0
root@dc2:/etc/chrony# ps axlf | grep chrony
0 0 15251 2599 20 0 6788 552 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony

My system is a Raspberry Pi 3.

processor : 3
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

Hardware : BCM2835
Revision : a22082
Serial : 00000000b222c465
Model : Raspberry Pi 3 Model B Rev 1.2

root@dc2:/etc/chrony# chronyd -d -d
2020-05-13T13:13:47Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2020-05-13T13:13:47Z Frequency -2.286 +/- 1.012 ppm read from /var/lib/chrony/chrony.drift
2020-05-13T13:13:52Z Selected source xxxx

root@dc2:/etc/chrony# chronyd
root@dc2:/etc/chrony# ps axlf | grep chrony
0 0 15502 2599 20 0 6788 572 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony
5 111 15490 1 20 0 12532 1896 poll_s S ? 0:00 chronyd

ubuntu@ubuntu:~$ systemctl status chrony

 chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset>
     Active: failed (Result: protocol) since Wed 2020-04-01 17:24:19 UTC; 6min >
       Docs: man:chronyd(8)
             man:chronyc(1)
             man:chrony.conf(5)
    Process: 1201 ExecStart=/usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON>
    Process: 1230 ExecStartPost=/usr/lib/chrony/chrony-helper update-daemon (co>

Apr 01 17:24:18 ubuntu systemd[1]: Starting chrony, an NTP client/server...
Apr 01 17:24:19 ubuntu chronyd[1224]: chronyd version 3.5 starting (+CMDMON +NT>
Apr 01 17:24:19 ubuntu systemd[1]: chrony.service: New main PID 1224 does not e>
Apr 01 17:24:19 ubuntu systemd[1]: chrony.service: Failed with result 'protocol>
Apr 01 17:24:19 ubuntu systemd[1]: Failed to start chrony, an NTP client/server.
lines 1-14/14 (END)
ubuntu@ubuntu:~$ cat /run/chronyd.pid
cat: /run/chronyd.pid: No such file or directory
ubuntu@ubuntu:~$ ps axlf | grep $(cat /run/chronyd.pid)
cat: /run/chronyd.pid: No such file or directory
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
ubuntu@ubuntu:~$ ps axlf | grep chrony
0 1000 1693 1676 20 0 5952 512 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony

root@ubuntu:/home/ubuntu# source /etc/default/chrony
root@ubuntu:/home/ubuntu# /usr/lib/systemd/scripts/chronyd-starter.sh $DAEMON_OPTS
root@ubuntu:/home/ubuntu# echo $?
0
root@ubuntu:/home/ubuntu# ps axlf | grep chrony
0 0 1712 1696 20 0 5952 520 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony

Hmm,
so chrony-pid doesn't exist and was properly cleaned up for you - odd.

But then starting the daemon seems to just work (no errors) yet then we get no running process.

We need to switch on more debug, would you mind running this:

$ bash -x /usr/lib/systemd/scripts/chronyd-starter.sh -d -F -1

That should
a) show what the script is doing due to the -x
b) show what chrony is doing and stay in foreground due to the -d

Hopefully that gives some more insight ...

root@ubuntu:/home/ubuntu# chronyd -d -d
2020-04-01T17:26:07Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2020-04-01T17:26:07Z Frequency -126.137 +/- 90.667 ppm read from /var/lib/chrony/chrony.drift
2020-04-01T17:26:15Z Selected source xxxx
2020-04-01T17:26:15Z System clock wrong by 3619768.248034 seconds, adjustment started
2020-05-13T14:55:43Z System clock was stepped by 3619768.248034 seconds
^C2020-05-13T14:57:31Z chronyd exiting
root@ubuntu:/home/ubuntu# chronyd
root@ubuntu:/home/ubuntu# ps axlf | grep chrony
0 0 1762 1547 20 0 5952 520 pipe_w S+ pts/0 0:00 \_ grep --color=auto chrony
5 112 1675 1 20 0 12356 1772 poll_s S ? 0:00 chronyd

root@ubuntu:/home/ubuntu# bash -x /usr/lib/systemd/scripts/chronyd-starter.sh -d -F -1
+ set -ue
+ CONF=/etc/default/chrony
+ DOC=/usr/share/doc/chrony/README.container
+ CAP=cap_sys_time
+ CMD=/usr/sbin/chronyd
+ EFFECTIVE_DAEMON_OPTS='-d -F -1'
+ '[' -f /etc/default/chrony ']'
+ . /etc/default/chrony
++ DAEMON_OPTS='-F -1'
++ SYNC_IN_CONTAINER=no
+ EFFECTIVE_SYNC_IN_CONTAINER=no
+ '[' '!' -x /usr/sbin/chronyd ']'
+ X_SET=0
+ getopts :x opt
+ case $opt in
+ getopts :x opt
+ case $opt in
+ getopts :x opt
+ case $opt in
+ getopts :x opt
+ '[' 0 -ne 1 ']'
+ IS_CONTAINER=0
+ '[' -x /usr/bin/systemd-detect-virt ']'
+ /usr/bin/systemd-detect-virt --quiet --container
+ HAS_CAP=1
+ CAPSH=/sbin/capsh
+ '[' -x /sbin/capsh ']'
+ /sbin/capsh --has-p=cap_sys_time
+ '[' 1 -eq 0 ']'
+ '[' 0 -eq 1 ']'
+ '[' 1 -eq 0 -o 0 -eq 1 ']'
+ /usr/sbin/chronyd -d -F -1
2020-05-13T15:01:29Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2020-05-13T15:01:29Z Frequency -2.045 +/- 41.568 ppm read from /var/lib/chrony/chrony.drift
/usr/lib/systemd/scripts/chronyd-starter.sh: line 70: 2091 Bad system call (core dumped) ${CMD} ${EFFECTIVE_DAEMON_OPTS}

Hey folks,

Sorry for my silence, I’m terribly busy lately…

Could you please install strace and run:
# strace -o /tmp/chronyd_debug.log chronyd -d -F -1

Then attach the output file (/tmp/chronyd_debug.log).

Thanks!

execve("/usr/sbin/chronyd", ["chronyd", "-d", "-F", "-1"], 0xbe9ae644 /* 24 vars */) = 0
brk(NULL) = 0x20e5000
uname({sysname="Linux", nodename="dc2", ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6ff8000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=33932, ...}) = 0
mmap2(NULL, 33932, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6fef000
close(3) = 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\350\221\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=362640, ...}) = 0
mmap2(NULL, 426104, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f68000
mprotect(0xb6fc0000, 61440, PROT_NONE) = 0
mmap2(0xb6fcf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x57000) = 0xb6fcf000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libnettle.so.7", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260a\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=177764, ...}) = 0
mmap2(NULL, 241864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f2c000
mprotect(0xb6f57000, 61440, PROT_NONE) = 0
mmap2(0xb6f66000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a000) = 0xb6f66000
close(3) = 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libcap.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\\\21\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=17888, ...}) = 0
mmap2(NULL, 82096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f17000
mprotect(0xb6f1b000, 61440, PROT_NONE) = 0
mmap2(0xb6f2a000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0xb6f2a000
close(3) = 0
openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libseccomp.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\374\331\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=144940, ...}) = 0
mmap2(NULL, 209148, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ee3000
mprotect(0xb6ef9000, 65536, PROT_NONE) = 0
mmap2(0xb6f09000, 57344, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0xb6f09000
close(3) = 0
openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libpthread.so.0", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0A[\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=116964, ...}) = 0
mmap2(NULL, 152152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6ebd000
mprotect(0xb6ed0000, 61440, PROT_NONE) = 0
mmap2(0xb6edf000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12000) =...

Thank you Robert.

So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter.
I’ll send a patch upstream.

Meanwhile, you can disable the seccomp filter by running (as root):
# sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony
# systemctl restart chrony.service

Hi all and no worries. I'm just glad to help where I can. See attachment for chronyd_debug.log

Seems I was a bit slow on the upload, but the oneliner works on my end as expected and chrony works as expected after a reboot. Thanks for the help.

Works for me as well. Thank you very much Vincent!

Thank you @Vincent - when you have a patch/link/commit let me know so I can tack the discussion and help doing merging the chrony upload into Groovy and an SRU into Focal.

I have already done some preliminary SRU paperwork on the bug description.

Found it - Upstream discussion at:
https://<email address hidden>/msg02161.html

Needs a minor rework to compile on older platforms (that miss clock_gettime64), but otherwise seems good.

Status changed to 'Confirmed' because the bug affects multiple users.

FYI - the upstream discussion on the details of the patch still goes on

Upstream the changes got applied, I expect that Debian gets a related upload soon'ish and will then merge it for Groovy - SRUs will then start from there.

chrony 3.5-9 now lands in Debian unstable with a fix (let’s hope) for this issue.
The patch might need to be refreshed to apply cleanly on top of chrony 3.5-6ubuntu6.

Yep, I'll merge 3.5-9 now which will also give me the test improvements that I recently submitted to you. The tests still keep failing sometimes, so that will help as well.
Once that is good in groovy I'll go for the SRU on top of 3.5-6ubuntu6.

@Vincent - have you found a clear reproducer for this as e.g. on my Raspberries it is not triggering. I'm running arm64 thou, maybe only armhf would be affected?

FYI - /me is trying an armhf image later on because that is the likely place to hit this ...

MP to merge 3.5-9 in Groovy
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/384237

MP to fix this in Focal:
https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/384238

@Christian - You won't encounter this problem on 64-bit architectures. These *time64 system calls are dedicated to 32-bit ones to make them Y2038-compatible.

FYI: Merge of 3.6-9 uploaded to Groovy

This bug was fixed in the package chrony - 3.5-9ubuntu1

---------------
chrony (3.5-9ubuntu1) groovy; urgency=medium

  * Merge with Debian unstable (LP: #1878005). Remaining changes:
    - d/chrony.conf: use ubuntu ntp pool and server (LP 1744664 1754358)
    - Set -x as default if unable to set time (e.g. in containers) (LP 1589780)
      Chrony is a single service which acts as both NTP client (i.e. syncing the
      local clock) and NTP server (i.e. providing NTP services to the network),
      and that is both desired and expected in the vast majority of cases.
      But in containers syncing the local clock is usually impossible, but this
      shall not break the providing of NTP services to the network.
      To some extent this makes chrony's default config more similar to 'ntpd',
      which complained in syslog but still provided NTP server service in those
      cases.
      + debian/chrony.service: allow the service to run without CAP_SYS_TIME
      + debian/control: add new dependency libcap2-bin for capsh (usually
        installed anyway, but make them explicit to be sure).
      + debian/chrony.default: new option SYNC_IN_CONTAINER to not fall back
        (Default off) [fixed a minor typo in the comment in this update]
      + debian/chronyd-starter.sh: wrapper to handle special cases in containers
        and if CAP_SYS_TIME is missing. Effectively allows to run NTP server in
        containers on a default installation and avoid failing to sync time (or
        if allowed to sync, avoid multiple containers to fight over it by
        accident).
      + debian/install: make chrony-starter.sh available on install.
      + debian/docs, debian/README.container: provide documentation about the
        handling of this case.
    - d/t/control: harden time-sources-from-dhcp-servers test for systemd change
      (LP: 1873031)
  * Dropped changes [in Debian now]
    - d/t/upstream-system-tests: stop chrony/systemd-timesynd before tests
    - d/t/upstream-system-tests: fix stderr in case services do not exist
    - Stop starting systemd-timesyncd in postrm. This is no longer relevant
      since systemd-timesyncd is a standalone package declaring
      Conflicts/Replaces/Provides: time-daemon. (Closes 955773, LP: 1872183)
    - d/postrm: Reinstate the remove target (LP: 1873810)

chrony (3.5-9) unstable; urgency=medium

  * debian/patches/:
    - Add allow-some-*time64-syscalls-in-seccomp-filter.patch. Needed for
    32-bit architectures with new system calls using 64-bit time_t.
    (LP: #1878005)

  * debian/tests/control:
    - Add needs-internet restriction to the upstream-simulation-test-suite
    test.

  [ Christian Ehrhardt ]
  * debian/tests/upstream-simulation-test-suite:
    - Skip if preparation steps fail.
    - Make preparation steps more verbose.

chrony (3.5-8) unstable; urgency=medium

  * debian/postrm:
    - Stop starting systemd-timesyncd in postrm. This is no longer relevant
    since systemd-timesyncd is a standalone package declaring
    Conflicts/Replaces/Provides: time-daemon. (Closes: #955773)

  [ Christian Ehrhardt ]
  * debian/tests/upstream-system-tests:
    - Stop chrony/systemd-timesynd before runnin...

Migrated in Groovy, uploaded to Focal-unapproved waiting on the SRU Team now.

Hello Jason, or anyone else affected,

Accepted chrony into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/chrony/3.5-6ubuntu6.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted chrony (3.5-6ubuntu6.1) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

chrony/3.5-6ubuntu6.1 (armhf)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#chrony

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Trying as-is on armhf:

After install I see the reported fail:
$ systemctl status chrony
● chrony.service - chrony, an NTP client/server
     Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
     Active: failed (Result: protocol) since Wed 2020-05-27 08:40:07 UTC; 1min 18s ago
       Docs: man:chronyd(8)
             man:chronyc(1)
             man:chrony.conf(5)

May 27 08:40:06 ubuntu systemd[1]: Starting chrony, an NTP client/server...
May 27 08:40:06 ubuntu chronyd[27223]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
May 27 08:40:06 ubuntu chronyd[27223]: Initial frequency 11.023 ppm
May 27 08:40:07 ubuntu systemd[1]: chrony.service: New main PID 27223 does not exist or is a zombie.
May 27 08:40:07 ubuntu systemd[1]: chrony.service: Failed with result 'protocol'.
May 27 08:40:07 ubuntu systemd[1]: Failed to start chrony, an NTP client/server.

Trying the daemon directly:
$ sudo chronyd -d -n -F 1
2020-05-27T08:43:29Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
2020-05-27T08:43:29Z Frequency 18.044 +/- 39.335 ppm read from /var/lib/chrony/chrony.drift
Bad system call

Installing the fix from proposed:

Upgrade works:
$ sudo apt install chrony
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
  chrony
1 upgraded, 0 newly installed, 0 to remove and 17 not upgraded.
Need to get 201 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ports.ubuntu.com/ubuntu-ports focal-proposed/main armhf chrony armhf 3.5-6ubuntu6.1 [201 kB]
Fetched 201 kB in 0s (1241 kB/s)
(Reading database ... 99010 files and directories currently installed.)
Preparing to unpack .../chrony_3.5-6ubuntu6.1_armhf.deb ...
Unpacking chrony (3.5-6ubuntu6.1) over (3.5-6ubuntu6) ...
Setting up chrony (3.5-6ubuntu6.1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3.1) ...

Now the process is fine

$ 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 Wed 2020-05-27 08:47:50 UTC; 58s ago
       Docs: man:chronyd(8)
             man:chronyc(1)
             man:chrony.conf(5)
   Main PID: 28356 (chronyd)
      Tasks: 2 (limit: 4915)
     CGroup: /system.slice/chrony.service
             ├─28356 /usr/sbin/chronyd -F -1
             └─28357 /usr/sbin/chronyd -F -1

May 27 08:47:50 ubuntu systemd[1]: Starting chrony, an NTP client/server...
May 27 08:47:50 ubuntu chronyd[28356]: chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
May 27 08:47:50 ubuntu chronyd[28356]: Frequency 18.044 +/- 39.335 ppm read from /var/lib/chrony/chrony.drift
May 27 08:47:50 ubuntu chronyd[28356]: Loaded seccomp filter
May 27 08:47:50 ubuntu systemd[1]: Started chrony, an NTP client/server.
May 27 08:47:59 ubuntu chronyd[28356]: Selected source 13...

FYI: The armhf test is known to be flaky, improved in groovy and retried in Bionic for this SRU.

Tests fixed, Verified - this is ready for Focal other than the aging period that needs to pass.

This bug was fixed in the package chrony - 3.5-6ubuntu6.1

---------------
chrony (3.5-6ubuntu6.1) focal; urgency=medium

  * d/patches/: Add allow-some-*time64-syscalls-in-seccomp-filter.patch
    (LP: #1878005) Thanks to Vincent Blut
    - backport time64 fix to 3.5-6 level

 -- Christian Ehrhardt <email address hidden> Wed, 20 May 2020 10:16:34 +0200

The verification of the Stable Release Update for chrony has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.