Bug#963121: Additional analysis and suggested bugfix

[Gert van de Kraats]

Problem also occurs at systemd version 245.6-2 .
Indeed I am using GNOME where the login session is managed
by systemd --user.
The problem is not concerning an ordinary user service, which is killed
by SIGKILL after 90 seconds. There is no SIGKILL-message!!
As described at the initial bug-text a restart of the user dbus may 
cause a hang at state
AUTHENTICATING during shutdown. At the log you can see
AUTHENTICATING starts at 18:10:02 and ends at 18:11:32, 90 seconds
later. State RUNNING is never reached.

Jun 15 18:10:02 debian systemd[1360]: Bus bus-api-user: changing state 
OPENING → AUTHENTICATING
Jun 15 18:11:32 debian systemd[1360]: Bus bus-api-user: changing state
AUTHENTICATING → CLOSED

In that hanging situation, as soon as the user systemd gets a SIGTERM 
from pid 1 (systemd) it will
call sd_bus_flush at libsystemd/sd-bus/sd-bus.c.
This will call bus_ensure_running, that repeats calling sd_bus_process,
that finally repeatingly calls bus_socket_process_authenticating.
This routine will cause a timeout after 90 seconds, the timeout-value is
hard coded by DEFAULT_TIMEOUT_USEC at basic/def.h .

A simple and tested patch at sd_bus_flush at libsystemd/sd-bus/sd-bus.c is
next code just before the call to bus_ensure_running:

         if ((bus->state == BUS_AUTHENTICATING) && (bus->is_user))
                 return -ETIMEDOUT;

It assumes state BUS_AUTHENTICATING is not normal for an user dbus at a 
call to sd_flush.

I think this is an upstream bug!