Your message dated Fri, 29 Jan 2016 00:10:10 +0100
with message-id <[email protected]>
and subject line Re: systemctl reload behaviour change between 204 and 208
has caused the Debian Bug report #759098,
regarding systemctl reload behaviour change between 204 and 208
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
759098: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759098
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 204-14
Severity: normal
File: /bin/systemctl
Hi,
While in systemd 204 reloading a service that is stopped is a noop and
exits with zero:
# systemctl stop virtlockd.service && systemctl reload virtlockd.service ; echo
$?
Warning: Stopping virtlockd.service, but it can still be activated by:
virtlockd.socket
0
It exits nonzero with 208:
# systemctl stop virtlockd.service && systemctl reloadvirtlockd.service ; echo
$?
Warning: Stopping virtlockd.service, but it can still be activated by:
virtlockd.socket Job for virtlockd.service failed. See 'systemctl
status virtlockd.service' and 'journalctl -xn' for details.
1
This broke libvirt-daemon-system which relied on the 204
behaviour. I've worked around this in the postinst but there's
potential for more breackage on users systems. The 204 behaviour
should probably be restored.
Cheers
-- Guido
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'unstable'),
(1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-rc6 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemd depends on:
ii acl 2.2.52-1
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-53.3
ii libacl1 2.2.52-1
ii libaudit1 1:2.3.7-1
ii libc6 2.19-7
ii libcap2 1:2.24-4
ii libcap2-bin 1:2.24-4
ii libcryptsetup4 2:1.6.4-4
ii libdbus-1-3 1.8.6-1
ii libgcrypt11 1.5.4-2
ii libkmod2 18-1
ii liblzma5 5.1.1alpha+20120614-2
ii libpam0g 1.1.8-3
ii libselinux1 2.3-1
ii libsystemd-daemon0 204-14
ii libsystemd-journal0 204-14
ii libsystemd-login0 204-14
ii libudev1 208-6
ii libwrap0 7.6.q-25
ii sysv-rc 2.88dsf-53.3
ii udev 208-6
ii util-linux 2.20.1-5.8
Versions of packages systemd recommends:
ii libpam-systemd 204-14
Versions of packages systemd suggests:
pn systemd-ui <none>
-- Configuration Files:
/etc/systemd/logind.conf changed [not included]
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Guido,
sorry for the late reply.
On Sun, 24 Aug 2014 11:06:05 +0200 Guido =?iso-8859-1?Q?G=FCnther?=
<[email protected]> wrote:
>
> While in systemd 204 reloading a service that is stopped is a noop and
> exits with zero:
...
> It exits nonzero with 208:
...
> This broke libvirt-daemon-system which relied on the 204
> behaviour. I've worked around this in the postinst but there's
> potential for more breackage on users systems. The 204 behaviour
> should probably be restored.
I agree that it was unfortuante that upstream changed behaviour in this way.
This was discussed in detail on the upstream mailing list [1],
especially the points about the reload semantics being changed [2]
> This isn't true. The reload semantics were changed in 6a371e23ee
> ("systemd: treat reload failure as failure"), after v208. Before that
> reload succeeded on stopped units. It's unclear what the rationale for
> this commit was, as the commit does not match the bug report given as
> explanation: the bug report talks about the case where the ExecReload
> command returns an error, but the commit changes a case where the
> ExecReload command is not executed at all and as such does not return
> any error. The commit message also says "documented to fail", but the
> only reference to documentation seems to be for the not-stopped case
> where ExecReload actually *is* executed and fails.
Lennart was quite clear, that he doesn't intend to change the behaviour
(back) and didn't until today. I also don't think it would be a good
idea to change such fundamental semantics downstream.
So, as there is nothing that can be done in Debian about this, I'm going
to close this bug report, even if this is probably not what you wanted
as a result.
Regards,
Michael
[1]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022048.html
[2]
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022123.html
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
