Bug#734848: [Pkg-systemd-maintainers] Bug#734848: systemd: LSB initscript wrappers should also handle sockets on start/stop

[Apollon Oikonomopoulos]

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