chrony exits unexpectedly

[Pedro Côrte-Real]

I've been running chrony with the default config except for disabling stepping the clock. I run it on a laptop that suspends/resumes frequently. I've noticed that it will sometimes just exit and not get restarted. There doesn't seem to be much of an explanation in the logs:

$ journalctl -r | grep chrony
Jun 29 16:02:08 coulson audit[765]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/chronyd" pid=765 comm="apparmor_parser"
Jun 29 16:01:41 coulson systemd[1]: Stopped chrony, an NTP client/server.
Jun 29 16:01:41 coulson systemd[1]: Stopping chrony, an NTP client/server...
Jun 29 16:01:41 coulson chronyd[14657]: chronyd exiting
Jun 29 15:56:41 coulson chronyd[14657]: Source 195.22.17.7 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 88.157.128.22 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 80.172.224.24 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 91.189.89.198 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 194.8.30.16 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 2001:67c:1560:8003::c8 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 2001:67c:1560:8003::c7 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 91.189.89.199 online
Jun 29 15:56:41 coulson chronyd[14657]: Forward time jump detected!
Jun 29 15:50:42 coulson chronyd[14657]: Source 195.22.17.7 offline
Jun 29 15:50:42 coulson chronyd[14657]: Source 88.157.128.22 offline
Jun 29 15:50:42 coulson chronyd[14657]: Source 80.172.224.24 offline
Jun 29 15:50:42 coulson chronyd[14657]: Source 91.189.89.198 offline
Jun 29 15:50:42 coulson chronyd[14657]: Source 194.8.30.16 offline

Starting it again works fine:

$ sudo service chrony start
$ journalctl -r | grep chrony
Jul 02 09:06:49 coulson systemd[1]: Started chrony, an NTP client/server.
Jul 02 09:06:49 coulson chronyd[7131]: Frequency 21.345 +/- 0.131 ppm read from /var/lib/chrony/chrony.drift
Jul 02 09:06:49 coulson chronyd[7131]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)
Jul 02 09:06:49 coulson systemd[1]: Starting chrony, an NTP client/server...
Jul 02 09:06:48 coulson sudo[7093]: pedrocr : TTY=pts/0 ; PWD=/home/pedrocr ; USER=root ; COMMAND=/usr/sbin/service chrony start

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: chrony 3.2-4ubuntu4.1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Mon Jul 2 09:03:56 2018
InstallationDate: Installed on 2018-05-31 (31 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
SourcePackage: chrony
UpgradeStatus: No upgrade log present (probably fresh install)

[Pedro Côrte-Real (pedrocr)]

Apparently the issue is just that chrony is not starting up on boot:

$ journalctl -r -u chrony | head -n 20
-- Logs begin at Thu 2018-05-31 12:51:22 WEST, end at Mon 2018-07-02 09:23:49 WEST. --
Jul 02 09:08:04 coulson chronyd[7131]: Selected source 194.8.30.16
Jul 02 09:06:58 coulson chronyd[7131]: Source 91.189.91.157 replaced with 2001:67c:1560:8003::c8
Jul 02 09:06:57 coulson chronyd[7131]: Selected source 91.189.94.4
Jul 02 09:06:49 coulson systemd[1]: Started chrony, an NTP client/server.
Jul 02 09:06:49 coulson chronyd[7131]: Frequency 21.345 +/- 0.131 ppm read from /var/lib/chrony/chrony.drift
Jul 02 09:06:49 coulson chronyd[7131]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)
Jul 02 09:06:49 coulson systemd[1]: Starting chrony, an NTP client/server...
-- Reboot --
Jun 29 16:01:41 coulson systemd[1]: Stopped chrony, an NTP client/server.
Jun 29 16:01:41 coulson systemd[1]: Stopping chrony, an NTP client/server...
Jun 29 16:01:41 coulson chronyd[14657]: chronyd exiting
Jun 29 15:56:41 coulson chronyd[14657]: Source 195.22.17.7 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 88.157.128.22 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 80.172.224.24 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 91.189.89.198 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 194.8.30.16 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 2001:67c:1560:8003::c8 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 2001:67c:1560:8003::c7 online
Jun 29 15:56:41 coulson chronyd[14657]: Source 91.189.89.199 online

even though it seems to be enabled:

$ systemctl is-enabled chrony
enabled

[Andreas Hasenack (ahasenack)]

While I try to reproduce this, could you please attach the custom config you said you have for chronyd, and where it is located exactly? systemd overrides, config file, etc

[Andreas Hasenack (ahasenack)]

If you have disabled stepping, maybe chrony gives up trying to adjust the clock when you come back from suspend and the clock is incorrect.

[Pedro Côrte-Real (pedrocr)]

The only custom config I have is to comment out the makestep line. Other than that I configure things through puppet in a very straightforward way:

class ntp {
  package {"openntpd":
    ensure => purged,
  }

  package {"ntpdate":
    ensure => purged,
  }

  package {"ntp":
    ensure => purged,
  }

  package {"chrony":
    ensure => present,
    require => Package['openntpd', 'ntpdate', 'ntp'],
  }

  file {'/etc/chrony/chrony.conf':
    ensure => present,
    owner => "root",
    group => "root",
    mode => '0644',
    source => 'puppet:///modules/ntp/chrony.conf',
    require => Package[chrony],
    notify => Service[chrony],
  }

  service {"chrony":
    ensure => running,
    enable => true,
    hasrestart => true,
    hasstatus => true,
  }
}

I don't know exactly what the "service" does to enable things in systemd but whatever it is hasn't worked apparently even though systemd does say it's enabled.

[Andreas Hasenack (ahasenack)]

Can you show the resulting /etc/chrony/chrony.conf file?

Also, my puppet-foo is rusty, but doesn't this mean all 3 packages will be installed alongside chrony:

package {"chrony":
    ensure => present,
    require => Package['openntpd', 'ntpdate', 'ntp'],
  }

[Pedro Côrte-Real (pedrocr)]

>If you have disabled stepping, maybe chrony gives up trying to adjust the clock when you come back from suspend and the clock is incorrect.

It doesn't seem to be the case in the logs. There's no error message on startup and when I start it manually it happily starts working.

>Also, my puppet-foo is rusty, but doesn't this mean all 3 packages will be installed alongside chrony:

That require line makes sure that before chrony is installed the other three are purged. That's because Package[openntpd/ntpdate/ntp] are defined above with "ensure => purged".

I did that so previous experiments with those other programs were guaranteed to be eliminated just in case.

> Can you show the resulting /etc/chrony/chrony.conf file?

It's literally the default file with just the stepping commented out:

"""
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usuable directives.

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
pool ntp.ubuntu.com iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1
pool 2.ubuntu.pool.ntp.org iburst maxsources 2

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
# makestep 1 3
"""

[Andreas Hasenack (ahasenack)]

I did an experiment with a bionic VM, where I installed chronyd and removed the "makestep" line. I then paused the VM and let it be for a while. About an hour later I unpaused it, and the clock was of course off. I rebooted it, and it came back up just fine with chronyd running and the clock adjusted.

It would help if you could give me some steps to try to reproduce this issue. Was your /var/log/chrony directory also empty during these apparent crashes?

Could you also please run "sudo systemctl status chronyd" right after the problem happened?

[Pedro Côrte-Real (pedrocr)]

I don't think these are crashes at all. The title of the bug needs to be changed. It seems that systemd is just not starting chrony on boot even though it does say it's enabled.

[Andreas Hasenack (ahasenack)]

But then it should happen at every reboot, unrelated to your suspends. Is that the case?

[Andreas Hasenack (ahasenack)]

Note it will not start if any of these other services are there:

Conflicts=systemd-timesyncd.service openntpd.service ntp.service

[Pedro Côrte-Real (pedrocr)]

It does seem to happen on every boot and it seems timesyncd is the problem:

$ systemctl is-enabled systemd-timesyncd
enabled

Seems more natural for the opposite to be the default. If chrony/ntp/openntpd is installed then the systemd version is disabled. Need to figure out how to disable this instead then.

[Pedro Côrte-Real (pedrocr)]

It does seem to happen on every boot and it seems timesyncd is the problem:

$ systemctl is-enabled systemd-timesyncd
enabled

This did the trick then:

  service {"systemd-timesyncd":
    ensure => stopped,
    enable => false,
    hasstatus => true,
  }

Seems more natural for the opposite to be the default. If chrony/ntp/openntpd is installed then the systemd version is disabled. It's strange that a simple "apt install chrony" doesn't result in a running chrony replacing systemd-timesyncd. The user has specifically decided to install chrony so it seems natural to assume he wants that instead of systemd and doesn't need to figure out why it's not running.

[Andreas Hasenack (ahasenack)]

Well, that is what happens actually, at least in my vm.

When I don't have chrony installed, timesyncd is running:
root@bionic-chrony:~# systemctl status systemd-timesyncd chronyd
Unit chronyd.service could not be found.
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-07-04 19:40:37 UTC; 13s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 521 (systemd-timesyn)
   Status: "Idle."
    Tasks: 2 (limit: 1152)
   CGroup: /system.slice/systemd-timesyncd.service
           └─521 /lib/systemd/systemd-timesyncd

The moment I install the chrony package, timesyncd is stopped:
root@bionic-chrony:~# apt install chrony
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  grub-pc-bin
Use 'apt autoremove' to remove it.
The following NEW packages will be installed:
  chrony
0 upgraded, 1 newly installed, 0 to remove and 74 not upgraded.
Need to get 203 kB of archives.
...
root@bionic-chrony:~# systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Wed 2018-07-04 19:41:23 UTC; 21s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 521 (code=exited, status=0/SUCCESS)
   Status: "Idle."

and chrony is now running:● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-07-04 19:41:23 UTC; 37s ago
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
 Main PID: 1371 (chronyd)
    Tasks: 1 (limit: 1152)
   CGroup: /system.slice/chrony.service
           └─1371 /usr/sbin/chronyd

both are seen as enabled, but just chrony is running:
root@bionic-chrony:~# systemctl is-enabled systemd-timesyncd chrony
enabled
enabled

This state is kept after a reboot: timesyncd stopped, chrony running.

[Andreas Hasenack (ahasenack)]

My previous statement was incorrect when I said that chrony would be disabled if timesyncd was installed, sorry. I seem to have misinterpreted the conflicts line.

[Robie Basak (racb)]

Am I right in thinking then that this report is currently unreproducible, so needs to remain Incomplete until we have steps to reproduce on a fresh system?

[Andreas Hasenack (ahasenack)]

I believe so.

[Pedro Côrte-Real (pedrocr)]

Seems like it's a systemd bug if anything then. I only got chrony to work by disabling timesyncd but apparently you can make this work without doing that.

The docs don't make it very clear that using conflicts will work properly:

"""
Conflicts=

    A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies.

    If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not the required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.
"""

It seems that depending on the boot order the chrony Conflicts line will result in timesysncd or chrony but never both to be started. Maybe for some reason my start order is different than the one you tested?

[Andreas Hasenack (ahasenack)]

After a reboot where chrony isn't running, can you run these commands and show their outputs:

sudo systemd-analyze critical-path

sudo journalctl -o short-monotonic -u systemd-timesyncd.service -u chrony.service

I'll do the same in my vm where chrony is working and let's compare notes.

[Pedro Côrte-Real (pedrocr)]

Reenabled systemd-timesyncd and am back to chrony not starting on boot so at least I can reproduce at will. Here are the outputs:

$ sudo systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @32.789s
└─multi-user.target @32.789s
  └─owserver.service @12.224s +1.060s
    └─network-online.target @12.222s
      └─NetworkManager-wait-online.service @4.481s +7.740s
        └─NetworkManager.service @4.211s +250ms
          └─dbus.service @4.007s
            └─basic.target @3.972s
              └─sockets.target @3.972s
                └─uuidd.socket @3.972s
                  └─sysinit.target @3.970s
                    └─systemd-timesyncd.service @3.840s +129ms
                      └─systemd-tmpfiles-setup.service @3.827s +11ms
                        └─local-fs.target @3.824s
                          └─run-user-1000-gvfs.mount @13.514s
                            └─run-user-1000.mount @12.399s
                              └─local-fs-pre.target @297ms
                                └─keyboard-setup.service @196ms +100ms
                                  └─systemd-journald.socket @193ms
                                    └─system.slice @193ms
                                      └─-.slice @191ms

$ sudo journalctl -o short-monotonic -u systemd-timesyncd.service -u chrony.service | head -n 20
-- Logs begin at Thu 2018-05-31 12:51:22 WEST, end at Thu 2018-07-05 18:23:07 WEST. --
[ 2.756688] coulson systemd[1]: Starting Network Time Synchronization...
[ 2.865804] coulson systemd[1]: Started Network Time Synchronization.
[ 33.233208] coulson systemd-timesyncd[292]: Synchronized to time server [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).
[ 722.864694] coulson systemd[1]: Stopping Network Time Synchronization...
[ 722.900591] coulson systemd[1]: Stopped Network Time Synchronization.
-- Reboot --
[ 9.812874] coulson systemd[1]: Starting Network Time Synchronization...
[ 9.949073] coulson systemd[1]: Started Network Time Synchronization.
[ 40.394096] coulson systemd-timesyncd[573]: Synchronized to time server [2001:67c:1560:8003::c7]:123 (ntp.ubuntu.com).
[10529.558443] coulson systemd-timesyncd[573]: Synchronized to time server [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).
[20405.821605] coulson systemd-timesyncd[573]: Synchronized to time server [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).
[29239.165550] coulson systemd-timesyncd[573]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com).
[34935.400396] coulson systemd-timesyncd[573]: Synchronized to time server 91.189.89.198:123 (ntp.ubuntu.com).
[64222.761628] coulson systemd-timesyncd[573]: Synchronized to time server 91.189.89.198:123 (ntp.ubuntu.com).
[77531.401846] coulson systemd-timesyncd[573]: Synchronized to time server [2001:67c:1560:8003::c8]:123 (ntp.ubuntu.com).
[79656.970968] coulson systemd[1]: Starting chrony, an NTP client/server...
[79656.971139] coulson systemd[1]: Stopping Network Time Synchronization...
[79656.997189] coulson systemd[1]: Stopped Network Time Synchronization.
[79657.110021] coulson chro...

[Andreas Hasenack (ahasenack)]

[79657.110021] coulson chronyd[23591]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)

if 79657 is seconds since reboot, how come it is so high if you just rebooted? Didn't you mean to use | tail instead of head?

[Pedro Côrte-Real (pedrocr)]

You're right. I haven't gotten used to journalctl yet. The other day I used it for the first time and ended doing -r to get reverse to paired it with head. Here's the correct output:

$ sudo journalctl -o short-monotonic -u systemd-timesyncd.service -u chrony.service | tail -n 20
[23363.712342] coulson chronyd[1008]: Source 195.22.17.7 online
[23363.712411] coulson chronyd[1008]: Source 91.189.94.4 online
[23817.610601] coulson chronyd[1008]: Source 2001:67c:1560:8003::c8 replaced with 91.189.89.199
[24351.347965] coulson chronyd[1008]: chronyd exiting
[24351.380512] coulson systemd[1]: Stopping chrony, an NTP client/server...
[24351.389046] coulson systemd[1]: Stopped chrony, an NTP client/server.
-- Reboot --
[ 8.099946] coulson systemd[1]: Starting Network Time Synchronization...
[ 8.229681] coulson systemd[1]: Started Network Time Synchronization.
[ 38.376727] coulson systemd-timesyncd[712]: Synchronized to time server 91.189.89.198:123 (ntp.ubuntu.com).

-- Here I manually started chrony --

[ 1073.902976] coulson systemd[1]: Starting chrony, an NTP client/server...
[ 1073.903330] coulson systemd[1]: Stopping Network Time Synchronization...
[ 1073.932511] coulson systemd[1]: Stopped Network Time Synchronization.
[ 1073.977280] coulson chronyd[3853]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)
[ 1073.978906] coulson chronyd[3853]: Frequency 22.532 +/- 1.122 ppm read from /var/lib/chrony/chrony.drift
[ 1074.084325] coulson systemd[1]: Started chrony, an NTP client/server.
[ 1080.970571] coulson chronyd[3853]: Selected source 91.189.89.198
[ 1092.162327] coulson chronyd[3853]: Source 2001:690:2100:80::4 replaced with 88.157.128.22
[ 1147.679352] coulson chronyd[3853]: Selected source 91.189.89.199
[ 1357.565918] coulson chronyd[3853]: Selected source 88.157.128.22

[Andreas Hasenack (ahasenack)]

Ok, could you please attach these files:

/lib/systemd/system/chrony.service
/lib/systemd/system/systemd-timesyncd.service

And if there are equivalent ones in /etc/systemd, those too. They could be overriding settings from the ones in /lib.

You might want to run this to find them:

find /lib/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls

Same for /etc:

find /etc/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls

On a working system, with both installed and where chrony is the only one starting up, I get:
root@bionic-chrony:~# find /lib/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls
     1801 4 -rw-r--r-- 1 root root 1342 Apr 20 16:55 /lib/systemd/system/systemd-timesyncd.service
    63916 4 -rw-r--r-- 1 root root 567 May 23 14:21 /lib/systemd/system/chrony.service
root@bionic-chrony:~# find /etc/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls
     1871 0 lrwxrwxrwx 1 root root 34 Jul 5 18:16 /etc/systemd/system/multi-user.target.wants/chrony.service -> /lib/systemd/system/chrony.service
      627 0 lrwxrwxrwx 1 root root 45 Jun 1 14:06 /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service

[Pedro Côrte-Real (pedrocr)]

The setup looks like the same:

$ find /lib/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls
   924954 4 -rw-r--r-- 1 root root 1342 Apr 20 17:55 /lib/systemd/system/systemd-timesyncd.service
   952832 4 -rw-r--r-- 1 root root 567 May 23 15:21 /lib/systemd/system/chrony.service
$ find /etc/systemd/ -name 'chrony.service' -ls -o -name 'systemd-timesyncd.service' -ls
   527802 0 lrwxrwxrwx 1 root root 45 Jul 5 18:18 /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service -> /lib/systemd/system/systemd-timesyncd.service
   547489 0 lrwxrwxrwx 1 root root 34 Jun 2 00:49 /etc/systemd/system/multi-user.target.wants/chrony.service -> /lib/systemd/system/chrony.service

[Andreas Hasenack (ahasenack)]

Yeah, it looks fine. I don't know what is going on. Our chrony expert is on holidays and will be back only in a week or so, maybe he can look at it the. Unless I can reproduce this problem, I cannot make progress at this time I'm afraid.

[Pedro Côrte-Real (pedrocr)]

I've fixed it with puppet anyway so I'm in no hurry. It does seem more like a systemd bug or usage issue than something specific to chrony. Maybe someone with systemd expertise would actually be the ideal.

[Pedro Côrte-Real (pedrocr)]

I talked about this issue in #systemd on freenode and things work like I suspected from the docs. Just enabling chrony and having that Conflicts line is not enough to guarantee that chrony and not timesyncd is started on startup. That just XORs between the two.

[Pedro Côrte-Real (pedrocr)]

After some more discussion it seems that the package needs to guarantee that timesyncd is disabled to make sure chrony is used. I suggest changing the title of the bug report to "Chrony install should automatically disable timesyncd".

[Andreas Hasenack (ahasenack)]

For reference, https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1764357 has a lot of history behind these decisions

[Pedro Côrte-Real (pedrocr)]

On the channel we discussed a potential systemd feature of having a ConflictsDisabled= line that chrony could set that would disable timesyncd if chrony was enabled. That would fix this issue while also fixing that one where actively uninstalling timesyncd on chrony install leaves you without a time sync daemon on chrony uninstall.

[Christian Ehrhardt  (paelzer)]

IIRC I think I had a discussion that when Conflicts are up alphabetical order wins.
So with "just" the conflicts not being perfect it should always be Chrony and never timesyncd that gets started when both are installed.

[Christian Ehrhardt  (paelzer)]

I was wondering if system might have changed from alphabetical to random order, but i na loop with more than 55 reboots always chrony won to be the active service (and timesynd off).
We'd need to find what shakes up this ordering in your case Pedro.

[Andreas Hasenack (ahasenack)]

Do you have any kind of override file for timesyncd and/or chrony (it could be named anything with a .conf extension) in the directories under /etc/systemd/system? If yes, could you please show its contents?

[Pedro Côrte-Real (pedrocr)]

$ find /etc/systemd/system/ -name "*.conf" | wc -l
0

$ find /etc/systemd/system/ -name "*.service" | wc -l
69

Nothing but service files. Considering how I enabled chrony with puppet instead of manually maybe that did something else differently?

[Launchpad Janitor (janitor)]

[Expired for chrony (Ubuntu) because there has been no activity for 60 days.]

[Pedro Côrte-Real (pedrocr)]

This was not Incomplete as far as I know. I provided the requested information.

[Andreas Hasenack (ahasenack)]

We don't have a clear reproducer for the issue, and we don't know what makes the boot ordering different on your system. So even though you provided the requested information, the bug is still incomplete because we don't have enough information to act on it, and we don't know at this time what else to request. I will set it to incomplete one more time, but we really need new information to act on this, as we haven't seen this happening anywhere else.

[Pedro Côrte-Real (pedrocr)]

Yeah, I don't really know how to help then. Maybe it's a locale issue that makes the sorting different? I seem to have everything set to "en_US.UTF-8" though but am not sure that was the case on initial install.

[Launchpad Janitor (janitor)]

[Expired for chrony (Ubuntu) because there has been no activity for 60 days.]