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
