Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Control: tags -1 wontfix Control: close -1 On Fri, 5 Dec 2014 07:43:49 +0100 Martin Pitt wrote: > Control: tag -1 -patch > > As the original patch needs some work, I'm removing the patch tag for > now. > > Thanks for your work! These legacy wrappers are all on their way out. It's been 10 years and it seems like this wasn't really needed in the end. Nowadays all packages should provide native units. Closing. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Control: tag -1 -patch As the original patch needs some work, I'm removing the patch tag for now. Thanks for your work! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Hi Michael, On 15:43 Sat 31 May , Michael Stapelberg wrote: +# We also start/stop the associated sockets (if any), so that +# /etc/init.d/foo stop permanently stops the service. +if [ $command = start -o $command = stop ]; then +for socket in $(systemctl list-unit-files --full --type=socket \ + --no-legend 2/dev/null \ +| sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do + +# Only handle successfully loaded sockets triggering this service +triggers=$(systemctl -p Triggers show $socket 2/dev/null) +state=$(systemctl -p LoadState show $service 2/dev/null) + +if [ $state = LoadState=loaded -a \ + $triggers = Triggers=$service ]; then +sockets=$socket $sockets +/bin/systemctl $command $socket This feels really clumsy. Why not ask systemd for all triggers of the service directly? E.g.: Yes you're right. I did experiment with TriggeredBy a bit, but it showed inconsistent behaviour, not always displaying the socket. I now realize that this was because the socket unit for the service I was testing with was loaded but not enabled. Unfortunately the semantics of TriggeredBy seem to be poorly documented. Anyway, I will submit a more elegant version :) By the way, there are currently three commonly used paths to trigger an initscript, all of them providing their own wrappers for systemd with different behaviours: • The direct route, calling /etc/init.d/service and relying on the initscript being a good LSB citizen. This is mostly used by system administrators. • /usr/sbin/invoke-rc.d, which currently provides its own wrapper logic and does not handle triggering units (see #734766). • /usr/sbin/service, which also provides its own logic and handles only triggering sockets. I think all three paths should exhibit the same behavior, ideally without code duplication. Two ways come into mind: • Provide a module with generic and reusable shell functions in the systemd package, that will offer high-level behaviour, e.g. handle service start if systemd is running. • Convince upstream to add a new higher-level systemctl subcommand that will start/stop a unit together with all its triggering units. I'd really appreciate your thoughts on this. Cheers, Apollon -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Hi Apollon, Apollon Oikonomopoulos apoi...@debian.org writes: was loaded but not enabled. Unfortunately the semantics of TriggeredBy seem to be poorly documented. Anyway, I will submit a more elegant version :) Cool. Also note that patches with documentation updates/clarifications are appreciated on the systemd-devel list. I think all three paths should exhibit the same behavior, ideally without code duplication. Two ways come into mind: • Provide a module with generic and reusable shell functions in the systemd package, that will offer high-level behaviour, e.g. handle service start if systemd is running. • Convince upstream to add a new higher-level systemctl subcommand that will start/stop a unit together with all its triggering units. Both ways require a new version of systemd to be uploaded to Debian, so none has a pragmatic advantage. I think it’d be worthwhile to attempt #2 first and fall back to #1 if upstream doesn’t want such a command. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Hi Apollon,
Thanks for providing a patch.
Apollon Oikonomopoulos apoi...@gmail.com writes:
diff --git a/debian/init-functions.d/40-systemd
b/debian/init-functions.d/40-systemd
index a213afc..e494ac2 100644
--- a/debian/init-functions.d/40-systemd
+++ b/debian/init-functions.d/40-systemd
@@ -40,6 +40,7 @@ systemctl_redirect () {
local rc
local prog=${1##*/}
local command=$2
+local sockets=
I think this should not only be limited to sockets, but to any
triggering unit. As an example, cups.service is triggered by cups.path
and cups.socket.
+# We also start/stop the associated sockets (if any), so that
+# /etc/init.d/foo stop permanently stops the service.
+if [ $command = start -o $command = stop ]; then
+for socket in $(systemctl list-unit-files --full --type=socket \
+ --no-legend 2/dev/null \
+| sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do
+
+# Only handle successfully loaded sockets triggering this service
+triggers=$(systemctl -p Triggers show $socket 2/dev/null)
+state=$(systemctl -p LoadState show $service 2/dev/null)
+
+if [ $state = LoadState=loaded -a \
+ $triggers = Triggers=$service ]; then
+sockets=$socket $sockets
+/bin/systemctl $command $socket
This feels really clumsy. Why not ask systemd for all triggers of the
service directly? E.g.:
for unit in $(systemctl -p TriggeredBy show $service | sed
's/^TriggeredBy=//g')
do
/bin/systemctl $command $unit
done
--
Best regards,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
tags 734848 +patch
thanks
Hi Michael,
On 23:25 Fri 10 Jan , Michael Stapelberg wrote:
Agreed. If you want to accelerate things, please attach a patch. Also,
FYI, I won’t work on this until #727708 is resolved.
Please find attached a patch implementing the suggested behaviour
(inspired mostly by /usr/sbin/service).
Regards,
Apollon
From 0bb95761cd8a71b9b6abc07f64ed6c34017d60cc Mon Sep 17 00:00:00 2001
From: Apollon Oikonomopoulos apoi...@debian.org
Date: Wed, 5 Feb 2014 19:20:00 +0200
Subject: [PATCH] LSB: start/stop service-triggering sockets
The LSB initscript wrapper functions handle starting/stopping individual
services, however they do not handle the corresponding sockets. The most
important effect of this is that /etc/init.d/foo stop will stop foo
only temporarily if foo is socket-activated, since the next connection
to the socket will cause systemd to re-activate the service.
We solve this issue by also stopping/starting any sockets triggering the
given service.
Closes: #734848
---
debian/init-functions.d/40-systemd | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/debian/init-functions.d/40-systemd b/debian/init-functions.d/40-systemd
index a213afc..e494ac2 100644
--- a/debian/init-functions.d/40-systemd
+++ b/debian/init-functions.d/40-systemd
@@ -40,6 +40,7 @@ systemctl_redirect () {
local rc
local prog=${1##*/}
local command=$2
+local sockets=
case $command in
start)
@@ -64,7 +65,27 @@ systemctl_redirect () {
state=$(systemctl -p LoadState show $service 2/dev/null)
[ $state = LoadState=masked ] return 0
-[ $command = status ] || log_daemon_msg $s $service
+# We also start/stop the associated sockets (if any), so that
+# /etc/init.d/foo stop permanently stops the service.
+if [ $command = start -o $command = stop ]; then
+for socket in $(systemctl list-unit-files --full --type=socket \
+ --no-legend 2/dev/null \
+| sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do
+
+# Only handle successfully loaded sockets triggering this service
+triggers=$(systemctl -p Triggers show $socket 2/dev/null)
+state=$(systemctl -p LoadState show $service 2/dev/null)
+
+if [ $state = LoadState=loaded -a \
+ $triggers = Triggers=$service ]; then
+sockets=$socket $sockets
+/bin/systemctl $command $socket
+fi
+done
+fi
+
+[ $command = status ] || log_daemon_msg $s ${sockets}${service}
+
/bin/systemctl $command $service
rc=$?
[ $command = status ] || log_end_msg $rc
--
2.0.0.rc0
signature.asc
Description: Digital signature
Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop
Hi Apollon, Apollon Oikonomopoulos apoi...@gmail.com writes: Currently the wrappers in /lib/lsb/init-functions.d/40-systemd will wrap starting/stopping any service with a corresponding systemd service unit file in a systemctl call. This works well with most services, however if a service supports socket activation and ships a socket unit, the socket will not be started/stopped during these operations. In the case of stop, this means that the service is not effectively stopped, but instead restarted, since it will be re-activated on the next connection. This is especially important for administrators, who tend to use /etc/init.d/service either directly or through scripts and expect the service to be permanently stopped after the stop action. Although there are unit-side workarounds for this (e.g. adding PartOf= to the socket unit definition), IMHO the desired behavior would be to detect if the service has a corresponding socket enabled, and start/stop this as well. For the record, this is also the behavior currently implemented by service(8) (which also checks that the socket actually triggers the given service). Agreed. If you want to accelerate things, please attach a patch. Also, FYI, I won’t work on this until #727708 is resolved. -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
