chrony install does not stop systemd-timesyncd
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chrony (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Xenial |
Won't Fix
|
Undecided
|
Unassigned | ||
Artful |
Won't Fix
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
Low
|
Unassigned | ||
ntp (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned | ||
Xenial |
Won't Fix
|
Low
|
Unassigned | ||
openntpd (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
1.
root@ubuntu:~# lsb_release -rd
Description: Ubuntu 16.04.4 LTS
Release: 16.04
root@ubuntu:~# uname -a
Linux ubuntu 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
2.
root@ubuntu:~# apt-cache policy systemd
systemd:
Installed: 229-4ubuntu21.1
Candidate: 229-4ubuntu21.1
Version table:
*** 229-4ubuntu21.1 500
500 http://
500 http://
100 /var/lib/
229-4ubuntu4 500
500 http://
root@ubuntu:~# apt-cache policy chrony
chrony:
Installed: 2.1.1-1
Candidate: 2.1.1-1
Version table:
*** 2.1.1-1 500
500 http://
100 /var/lib/
3. installing chrony should stop systemd-timesyncd so they both don't try to adjust time
4. after chrony is installed both systemd-timesyncd and chronyd are running.
root@ubuntu:~# ps aux | egrep "(chrony|timesync)"
systemd+ 1086 0.0 0.2 100324 2368 ? Ssl 19:34 0:00 /lib/systemd/
_chrony 2770 0.0 0.2 105780 2920 ? S 19:38 0:00 /usr/sbin/chronyd
root 3077 0.0 0.0 12944 924 pts/0 S+ 19:52 0:00 grep -E --color=auto (chrony|timesync)
Note, on bionic the chrony package successfully stops systemd-timesyncd and only chronyd remains running after install.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: chrony 2.1.1-1
ProcVersionSign
Uname: Linux 4.4.0-116-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.15
Architecture: amd64
Date: Mon Mar 19 19:51:06 2018
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: chrony
UpgradeStatus: No upgrade log present (probably fresh install)
The way the newer versions solve this is to have a native systemd service and in there there is:
Conflicts= systemd- timesyncd. service openntpd.service
That ensures only one of these can be started.
Xenial has no systemd service at all, it has sysV and uses the systemd generator.
So there is no "just add the line" fix available.
Xenial as-is timesyncd. service timesyncd. service - Network Time Synchronization system/ systemd- timesyncd. service; enabled; vendor preset: enabled) system/ systemd- timesyncd. service. d
└─disable- with-time- daemon. conf
$ timedatectl status
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
systemctl status systemd-
● systemd-
Loaded: loaded (/lib/systemd/
Drop-In: /lib/systemd/
Active: active (running) since Wed 2018-03-21 16:00:19 UTC; 1min 30s ago
This isn't even fully protected if you install ntp (not chrony) as it was the ntp server back in Xenial. (Right after install it still runs).
What stops it there for NTPd is that this uses a config dir which pulls in: systemd/ system/ systemd- timesyncd. service. d/disable- with-time- daemon. conf
/lib/
So any further starts will be blocked: Executable= !/usr/sbin/ ntpd Executable= !/usr/sbin/ openntpd Executable= !/usr/sbin/ chronyd Executable= !/usr/sbin/ VBoxService
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIs
ConditionFileIs
ConditionFileIs
ConditionFileIs
You see that if you check systemd- timesyncd. service: timesyncd. service timesyncd. service - Network Time Synchronization system/ systemd- timesyncd. service; enabled; vendor preset: enabled) system/ systemd- timesyncd. service. d
└─disable- with-time- daemon. conf
ConditionFi leIsExecutable= !/usr/sbin/ ntpd was not met
$ systemctl status systemd-
● systemd-
Loaded: loaded (/lib/systemd/
Drop-In: /lib/systemd/
Active: inactive (dead)
Condition: start condition failed at Wed 2018-03-21 16:06:42 UTC; 44s ago
After installing Chrony this is the same:
Condition: start condition failed at Wed 2018-03-21 16:11:37 UTC; 1s ago
ConditionFi leIsExecutable= !/usr/sbin/ chronyd was not met
That is good (no special issue to chrony) and bad (actually all timeservers "collide" right after install).
A reboot or restart will pick that up.
OTOH it is discouraged to start/stop/restart other packages services form a postinst - as the first thought would be to do refresh for that condition after installing any of these.
Given that there was not a single complaint about it in 2 years of Xenial other than us now looking for it in detail I'd rate it low, but it is a valid issue.