Bug#1150037: gnome-session-bin: D-Bus restart races with queued portal activation during logout, delaying next login by 120s

[Claus Fischer]

Package: gnome-session-bin
Version: 48.0-1+deb13u1
Severity: important

During shutdown of a GNOME Wayland session, |gnome-session-ctl|can fail 
to restart the persistent user D-Bus if a D-Bus-activated service 
concurrently causes |xdg-desktop-portal.service|to be queued for startup.

This leaves the old user-bus/portal state behind and can delay 
application startup after the following graphical login until 
D-Bus/portal activation timeouts of 120 seconds expire.

I have a reproducible A/B test for the race.

The affected system is Debian 13 (trixie), GNOME 48, Wayland. I also 
have persistent SSH sessions, so the systemd user manager and user D-Bus 
remain alive across graphical logout.

In my case the trigger is a late D-Bus activation of Nextcloud by 
Firefox. This is a separate known Nextcloud issue and is not the bug I 
am reporting here; it merely provides a reliable way of triggering the 
gnome-session race.

During logout, after the normal Nextcloud instance has already been 
terminated, Firefox requests:

|com.nextcloudgmbh.Nextcloud|

D-Bus starts:

|/usr/bin/nextcloud --background|

The graphical session is already being torn down, so this newly started 
Nextcloud process cannot connect to Wayland/X11. Before terminating, 
however, it requests:

|org.freedesktop.portal.Desktop|

This queues |xdg-desktop-portal.service|for startup just as GNOME runs 
|gnome-session-restart-dbus.service|.

The journal then shows:

|systemd: Starting xdg-desktop-portal.service - Portal service... 
systemd: Starting gnome-session-restart-dbus.service - Restart DBus 
after GNOME Session shutdown... systemd: Requested transaction 
contradicts existing jobs: Transaction for dbus.service/stop is 
destructive (xdg-desktop-portal.service has 'start' job queued, but 
'stop' is included in transaction). gnome-session-ctl: Failed to restart 
DBus service: 
GDBus.Error:org.freedesktop.systemd1.TransactionIsDestructive: 
Transaction for dbus.service/stop is destructive 
(xdg-desktop-portal.service has 'start' job queued, but 'stop' is 
included in transaction).|

At this point |graphical-session.target|is already inactive. The newly 
started portal attempts to activate the GNOME portal backend, which 
consequently fails its dependency.

The graphical logout itself completes. However, the intended restart of 
the user D-Bus has failed.

After the next graphical login, portal activation becomes stuck. The 
journal subsequently shows errors including:

|Error calling StartServiceByName for org.freedesktop.portal.Desktop: 
Timeout was reached|

and:

|xdg-desktop-portal.service: start operation timed out. Terminating.|

Eventually D-Bus reports activation timeouts with:

|service_start_timeout=120000ms|

During this interval applications launched from the desktop appear not 
to start. They eventually appear together after the timeout/race has 
resolved.

I can prevent the triggering activation without otherwise changing the 
session by installing this per-user D-Bus override:

|~/.local/share/dbus-1/services/com.nextcloudgmbh.Nextcloud.service|

containing:

|[D-BUS Service] Name=com.nextcloudgmbh.Nextcloud Exec=/bin/false|

This provides a reproducible A/B test.

With the override installed, Firefox makes exactly the same request for 
|com.nextcloudgmbh.Nextcloud|during logout, but activation fails 
immediately.

The journal then shows, in the same second:

|Activated service 'com.nextcloudgmbh.Nextcloud' failed: Process 
com.nextcloudgmbh.Nextcloud exited with status 1 Starting 
gnome-session-restart-dbus.service - Restart DBus after GNOME Session 
shutdown... Started gnome-session-restart-dbus.service - Restart DBus 
after GNOME Session shutdown. Stopping dbus.service - D-Bus User Message 
Bus... Stopped dbus.service - D-Bus User Message Bus.|

The following login is immediate.

Nextcloud is then started normally by GNOME autostart. It requests 
|org.freedesktop.portal.Desktop|, and the portal services start normally 
within approximately one second.

I repeated this test, including deliberately waiting until a Nextcloud 
desktop notification appeared before launching applications. Application 
startup remained immediate. Thus the notifications are unrelated to the 
delay.

The Nextcloud D-Bus activation problem has separately been reported as a 
follow-up to Debian bug #1072382 and upstream in Nextcloud Desktop issue 
#7653. It is not necessary for this gnome-session bug: any sufficiently 
late D-Bus activation which queues a service depending on 
|dbus.service|appears capable of producing the race.

The problem here is that |gnome-session-restart-dbus.service|is 
specifically intended to restart the persistent user bus after 
graphical-session shutdown, but a concurrently queued D-Bus activation 
can make that restart fail with |TransactionIsDestructive|. The failure 
then leaves state from the old graphical session in the persistent user 
manager and affects the following login.

I believe gnome-session should ensure that the intended D-Bus restart 
completes even when another D-Bus activation races with session 
shutdown. At minimum, |TransactionIsDestructive|should not cause the 
restart to be abandoned without recovery.

Relevant versions:

|gnome-session-bin 48.0-1+deb13u1 gnome-session-common 48.0-1+deb13u1 
systemd 257.13-1~deb13u1 dbus-user-session 1.16.2-2 firefox-esr 
140.16.0esr-1~deb13u1 nextcloud-desktop 3.16.7-1~deb13u1 
xdg-desktop-portal 1.22.1+ds-1~bpo13+1 xdg-desktop-portal-gnome 48.0-2 
fuse3 3.18.3-1~bpo13+1 libfuse3-4 3.18.3-1~bpo13+1|

|xdg-desktop-portal|1.22.1 and FUSE 3.18.3 are local backports built 
from Debian testing source on Debian 13. I installed them while 
investigating an earlier, separate |xdg-document-portal|shutdown problem.

The D-Bus restart race described above occurred after those newer 
versions were already installed. In particular, 
|xdg-document-portal|itself stopped and started promptly in the tests 
described here.

The affected computer is older hardware (from 2018), but otherwise 
performs normally. The observed delay is not general system slowness: it 
corresponds to explicit 120-second service activation timeouts and 
disappears completely in the A/B test above.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20261005/74682c52/attachment-0001.htm>