[systemd-devel] Dependencies on DBus activated services during shutdown

[Simon McVittie]

On Mon, 08 Jan 2018 at 16:07:48 +0100, Michal Koutný wrote:
> As it comes, A.service needs B.service for proper termination. During
> the shutdown transaction there is unspecified ordering of the two (since
> the dependency is implicit only) and B.service is stopped before A.service.

Does A.service even need B.service during shutdown if it has not
previously interacted with (=> started) B.service?

Or is the issue that B.service handles requests from A.service, then shuts
down when unused (leaving "background" state that it's responsible for),
and during shutdown, A.service needs to wake B.service back up to undo
those requests?

> I know this could be circumvented by explicitly specifying
> After=b.service for the A.service

To be honest that doesn't seem too bad to me.

On Mon, 08 Jan 2018 at 16:53:04 +0100, Jérémy Rosen wrote:
> That means that the only way to fix that without explicitely telling someone
> about the dependency is to allow dbus to start units while its shutdown is
> pending [...] this seems to be explicitely forbidden

I didn't write that special case, but I agree with it. Starting D-Bus
services while the sword of Damocles is hanging over dbus-daemon's
head does not sound like a route to guaranteed success. As soon as
dbus-daemon gets SIGTERM, they'll find that their D-Bus AF_UNIX socket
is rather less useful than it was a moment ago...

If A.service can be made to shut down correctly without B.service,
then that seems good in any case. (What happens if B.service crashes?)

Failing that, if A.service genuinely needs D-Bus during its shutdown,
it probably also makes sense to serialize it After=dbus.service (not
just dbus.socket) so that dbus-daemon will be kept alive until A.service
actually exits.

If systemd had an asymmetric StopBefore=dbus.service, that could be used
here (and also for <https://bugs.freedesktop.org/show_bug.cgi?id=89847>);
but it doesn't (and I can see why the systemd maintainers want to preserve
the symmetry of startup/shutdown order), and After=dbus.service is
the next best thing. I agree with Lennart's assertion on that bug that
having ExecStop pretend to stop dbus-daemon, but not actually do it,
is the wrong answer.

    smcv