Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#902026: systemd: "systemctl start systemd-timesyncd.service" kills chrony
348 views
Skip to first unread message
Francesco Poli (wintermute)
Jun 21, 2018, 1:40:03 PM6/21/18
to
Package: systemd
Version: 238-5
Severity: normal
Dear systemd Debian package maintainers,
it seems I found out a regression of systemd-timesyncd.
It used to refuse to start, whenever other NTP clients (such as chrony)
were used.
If I read bug #805927 correctly, now this is accomplished with
other NTP clients shipping service files with an appropriate
"Conflicts=systemd-timesyncd.service" directive.
However, this does not seem to work as expected.
Please let me explain.
I have chrony running on my system, and its service file seems
to satisfy the above requirement:
$ cat /lib/systemd/system/chrony.service
[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=systemd-timesyncd.service openntpd.service ntp.service
After=network.target
ConditionCapability=CAP_SYS_TIME
[Service]
Type=forking
PIDFile=/run/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
ExecStartPost=-/usr/lib/chrony/chrony-helper update-daemon
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
[Install]
Alias=chronyd.service
WantedBy=multi-user.target
But, as soon as I issue:
# service systemd-timesyncd start
chrony dies and systemd-timesyncd starts.
I thought that systemd-timesyncd should refrain from starting and
leave chrony alone.
I think this misbehavior happens whenever all the services are
started (e.g.: at boot, when "systemctl daemon-reexec" is issued,
and so forth...).
This is very annoying.
My expectation is that the installation of chrony should automatically
disable systemd-timesyncd.
It used to work this way in the past, but it no longer seems to be the
case...
Could you please investigate and fix this issue?
Thanks for your time.
Bye!
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages systemd depends on:
ii adduser 3.117
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.12-4
ii libaudit1 1:2.8.3-1
ii libblkid1 2.32-0.1
ii libc6 2.27-3
ii libcap2 1:2.25-1.2
ii libcryptsetup12 2:2.0.2-1
ii libgcrypt20 1.8.3-1
ii libgpg-error0 1.31-1
ii libidn11 1.33-2.2
ii libip4tc0 1.6.2-1
ii libkmod2 25-1
ii liblz4-1 1.8.2-1
ii liblzma5 5.2.2-1.3
ii libmount1 2.32-0.1
ii libpam0g 1.1.8-3.7
ii libseccomp2 2.3.3-2
ii libselinux1 2.8-1
ii libsystemd0 238-5
ii mount 2.32-0.1
ii procps 2:3.3.15-2
ii util-linux 2.32-0.1
Versions of packages systemd recommends:
ii dbus 1.12.8-3
ii libpam-systemd 238-5
Versions of packages systemd suggests:
ii policykit-1 0.105-20
pn systemd-container <none>
Versions of packages systemd is related to:
pn dracut <none>
ii initramfs-tools 0.130
ii udev 238-5
-- no debconf information
Version: 238-5
Severity: normal
Dear systemd Debian package maintainers,
it seems I found out a regression of systemd-timesyncd.
It used to refuse to start, whenever other NTP clients (such as chrony)
were used.
If I read bug #805927 correctly, now this is accomplished with
other NTP clients shipping service files with an appropriate
"Conflicts=systemd-timesyncd.service" directive.
However, this does not seem to work as expected.
Please let me explain.
I have chrony running on my system, and its service file seems
to satisfy the above requirement:
$ cat /lib/systemd/system/chrony.service
[Unit]
Description=chrony, an NTP client/server
Documentation=man:chronyd(8) man:chronyc(1) man:chrony.conf(5)
Conflicts=systemd-timesyncd.service openntpd.service ntp.service
After=network.target
ConditionCapability=CAP_SYS_TIME
[Service]
Type=forking
PIDFile=/run/chronyd.pid
EnvironmentFile=-/etc/default/chrony
ExecStart=/usr/sbin/chronyd $DAEMON_OPTS
ExecStartPost=-/usr/lib/chrony/chrony-helper update-daemon
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full
[Install]
Alias=chronyd.service
WantedBy=multi-user.target
But, as soon as I issue:
# service systemd-timesyncd start
chrony dies and systemd-timesyncd starts.
I thought that systemd-timesyncd should refrain from starting and
leave chrony alone.
I think this misbehavior happens whenever all the services are
started (e.g.: at boot, when "systemctl daemon-reexec" is issued,
and so forth...).
This is very annoying.
My expectation is that the installation of chrony should automatically
disable systemd-timesyncd.
It used to work this way in the past, but it no longer seems to be the
case...
Could you please investigate and fix this issue?
Thanks for your time.
Bye!
-- Package-specific info:
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages systemd depends on:
ii adduser 3.117
ii libacl1 2.2.52-3+b1
ii libapparmor1 2.12-4
ii libaudit1 1:2.8.3-1
ii libblkid1 2.32-0.1
ii libc6 2.27-3
ii libcap2 1:2.25-1.2
ii libcryptsetup12 2:2.0.2-1
ii libgcrypt20 1.8.3-1
ii libgpg-error0 1.31-1
ii libidn11 1.33-2.2
ii libip4tc0 1.6.2-1
ii libkmod2 25-1
ii liblz4-1 1.8.2-1
ii liblzma5 5.2.2-1.3
ii libmount1 2.32-0.1
ii libpam0g 1.1.8-3.7
ii libseccomp2 2.3.3-2
ii libselinux1 2.8-1
ii libsystemd0 238-5
ii mount 2.32-0.1
ii procps 2:3.3.15-2
ii util-linux 2.32-0.1
Versions of packages systemd recommends:
ii dbus 1.12.8-3
ii libpam-systemd 238-5
Versions of packages systemd suggests:
ii policykit-1 0.105-20
pn systemd-container <none>
Versions of packages systemd is related to:
pn dracut <none>
ii initramfs-tools 0.130
ii udev 238-5
-- no debconf information
Francesco Poli
Jun 21, 2018, 3:30:03 PM6/21/18
to
On Thu, 21 Jun 2018 20:47:36 +0200 Michael Biebl wrote:
> Am 21.06.2018 um 19:36 schrieb Francesco Poli (wintermute):
[...]
> > systemd-timesyncd
[...]
But then, this can happen whenever services are (re-)started, such as
at boot time or when "systemctl daemon-reexec" is issued.
Depending on the order for the various services, this could result in
having to manually restart chrony, just to stop systemd-timesyncd...
>
> > I thought that systemd-timesyncd should refrain from starting and
> > leave chrony alone.
>
> No, Conflicts work both ways.
>
> Afaics, everything is working as expected, so closing this bug report.
Wait, let me clarify how I see it.
Some time ago, I just had to install chrony (and set it up) in
order to make it work, without systemd-timesyncd interfering.
Now, it seems that I will *also* have to manually issue the following
command:
# systemctl --now mask systemd-timesyncd
before installing and configuring chrony.
Is this correct?
This looks like a regression.
Do you agree?
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
> Am 21.06.2018 um 19:36 schrieb Francesco Poli (wintermute):
[...]
> > systemd-timesyncd
[...]
> > used to refuse to start, whenever other NTP clients (such as chrony)
> > were used.
[...]
> > were used.
> > But, as soon as I issue:
> >
> > # service systemd-timesyncd start
> >
> > chrony dies and systemd-timesyncd starts.
>
> If you manually start systemd-timesyncd, then indeed chronyd is stopped
> >
> > # service systemd-timesyncd start
> >
> > chrony dies and systemd-timesyncd starts.
>
But then, this can happen whenever services are (re-)started, such as
at boot time or when "systemctl daemon-reexec" is issued.
Depending on the order for the various services, this could result in
having to manually restart chrony, just to stop systemd-timesyncd...
>
> > I thought that systemd-timesyncd should refrain from starting and
> > leave chrony alone.
>
>
> Afaics, everything is working as expected, so closing this bug report.
Wait, let me clarify how I see it.
Some time ago, I just had to install chrony (and set it up) in
order to make it work, without systemd-timesyncd interfering.
Now, it seems that I will *also* have to manually issue the following
command:
# systemctl --now mask systemd-timesyncd
before installing and configuring chrony.
Is this correct?
This looks like a regression.
Do you agree?
--
http://www.inventati.org/frx/
There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Francesco Poli
Jun 21, 2018, 4:20:03 PM6/21/18
to
On Thu, 21 Jun 2018 21:57:29 +0200 Michael Biebl wrote:
> Am 21.06.2018 um 21:16 schrieb Francesco Poli:
[...]
Weird!
The fact is that, at some point, I found out that chrony was no longer
running on my box, while systemd-timesyncd was somehow running instead.
I am pretty sure I had *not* manually issued a "service
systemd-timesyncd start" command before that point in time.
I only issued that command afterwards, while investigating the mystery,
and saw that it had the power to stop chrony.
Do you have any idea about what could have happened?
Thanks for your prompt replies and for any additional help you may
provide!
> Am 21.06.2018 um 21:16 schrieb Francesco Poli:
[...]
> > Now, it seems that I will *also* have to manually issue the following
> > command:
> >
> > # systemctl --now mask systemd-timesyncd
> >
> > before installing and configuring chrony.
> >
> > Is this correct?
> >
>
> No, this is not correct.
> > command:
> >
> > # systemctl --now mask systemd-timesyncd
> >
> > before installing and configuring chrony.
> >
> > Is this correct?
> >
>
Weird!
The fact is that, at some point, I found out that chrony was no longer
running on my box, while systemd-timesyncd was somehow running instead.
I am pretty sure I had *not* manually issued a "service
systemd-timesyncd start" command before that point in time.
I only issued that command afterwards, while investigating the mystery,
and saw that it had the power to stop chrony.
Do you have any idea about what could have happened?
Thanks for your prompt replies and for any additional help you may
provide!
Francesco Poli
Jun 21, 2018, 5:40:02 PM6/21/18
to
On Thu, 21 Jun 2018 22:52:37 +0200 Michael Biebl wrote:
[...]
> I would check the journal and try to correlate it with other events
> based on the timestamp
By looking at the journal timestamps and the root bash history, it
really seems that chrony was stopped (and timesyncd was started) when I
issued the commands:
# systemctl daemon-reexec
# service systemd-logind restart
I will look more carefully next time, and I will check if/when chrony
gets stopped.
Bye and thanks for your help so far!
[...]
> I would check the journal and try to correlate it with other events
> based on the timestamp
By looking at the journal timestamps and the root bash history, it
really seems that chrony was stopped (and timesyncd was started) when I
issued the commands:
# systemctl daemon-reexec
# service systemd-logind restart
I will look more carefully next time, and I will check if/when chrony
gets stopped.
Bye and thanks for your help so far!
Francesco Poli
Jun 22, 2018, 6:00:03 PM6/22/18
to
On Fri, 22 Jun 2018 01:28:42 +0200 Michael Biebl wrote:
> Am 22.06.2018 um 01:24 schrieb Michael Biebl:
>
> > Fwiw, I'm aware of
> > https://github.com/systemd/systemd/issues/7104
> >
>
> You might also be interested in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895821
Michael,
thanks for the additional info.
I'll try to keep an eye on the two daemons, to find out which one is
running and whether something unexpected happens.
Bye.
> Am 22.06.2018 um 01:24 schrieb Michael Biebl:
>
> > Fwiw, I'm aware of
> > https://github.com/systemd/systemd/issues/7104
> >
>
> You might also be interested in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895821
Michael,
thanks for the additional info.
I'll try to keep an eye on the two daemons, to find out which one is
running and whether something unexpected happens.
Bye.
Francesco Poli
Jul 23, 2018, 2:00:03 PM7/23/18
to
Control: reopen -1
Control: retitle -1 systemd: systemd-timesyncd should not run, when chronyd is running
On Fri, 22 Jun 2018 23:46:57 +0200 Francesco Poli wrote:
[...]
At each reboot, both daemons (chrony and systemd-timesyncd) are running
simultaneously!
Please take a look at the attached transcripts.
I have to manually stop systemd-timesyncd with
# service systemd-timesyncd stop
after each boot.
I am again pondering whether I should mask systemd-timesyncd with
# systemctl --now mask systemd-timesyncd
I hope this won't be needed...
Control: retitle -1 systemd: systemd-timesyncd should not run, when chronyd is running
On Fri, 22 Jun 2018 23:46:57 +0200 Francesco Poli wrote:
[...]
> I'll try to keep an eye on the two daemons, to find out which one is
> running and whether something unexpected happens.
Well, something weird is indeed happening.
> running and whether something unexpected happens.
At each reboot, both daemons (chrony and systemd-timesyncd) are running
simultaneously!
Please take a look at the attached transcripts.
I have to manually stop systemd-timesyncd with
# service systemd-timesyncd stop
after each boot.
I am again pondering whether I should mask systemd-timesyncd with
# systemctl --now mask systemd-timesyncd
Francesco Poli
Jul 24, 2018, 3:40:03 PM7/24/18
to
On Tue, 24 Jul 2018 01:46:51 +0200 Michael Biebl wrote:
> Am 23.07.2018 um 19:53 schrieb Francesco Poli:
[...]
OK, I disabled systemd-timesyncd: I hope this will work around the bug.
However, do you agree that the Conflicts is not working properly?
I think this is a bug in systemd...
> Am 23.07.2018 um 19:53 schrieb Francesco Poli:
[...]
> > I am again pondering whether I should mask systemd-timesyncd with
> >
> > # systemctl --now mask systemd-timesyncd
>
> systemctl disable systemd-timesyncd should be sufficient
> >
> > # systemctl --now mask systemd-timesyncd
>
OK, I disabled systemd-timesyncd: I hope this will work around the bug.
However, do you agree that the Conflicts is not working properly?
I think this is a bug in systemd...
Francesco Poli
Jul 24, 2018, 4:20:03 PM7/24/18
to
On Tue, 24 Jul 2018 22:02:11 +0200 Michael Biebl wrote:
> Am 24.07.2018 um 21:33 schrieb Francesco Poli:
[...]
Ah, it really looks similar to the bug I am experiencing.
Maybe it could be considered as the upstream-forward for my bug
report...
> Am 24.07.2018 um 21:33 schrieb Francesco Poli:
[...]
> > However, do you agree that the Conflicts is not working properly?
>
> Well, see https://github.com/systemd/systemd/issues/7104
>
Ah, it really looks similar to the bug I am experiencing.
Maybe it could be considered as the upstream-forward for my bug
report...
0 new messages