Bug#974432: xfce4-notifyd fails to start in ssh session; long timeout
Package: xfce4-notifyd
Version: 0.4.3-1
Severity: normal
(Possibly related to #899377, but that report isn't about remote sessions.)
When dbus-daemon tries to start xfce4-notifyd from within an ssh session (with
X forwarding), this fails after a 2-minute timeout. Typical log entries:
Nov 11 16:57:49 HOST systemd[18064]: Starting XFCE notifications service...
Nov 11 16:57:49 HOST xfce4-notifyd[32729]: Unable to init server: Could not connect: Connection refused
Nov 11 16:57:49 HOST xfce4-notifyd[32729]: cannot open display:
Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE
Nov 11 16:57:49 HOST systemd[18064]: xfce4-notifyd.service: Failed with result 'exit-code'.
Nov 11 16:57:49 HOST systemd[18064]: Failed to start XFCE notifications service.
Nov 11 16:59:49 HOST dbus-daemon[32186]: [session uid=UID pid=32186] Failed to activate service 'org.freedesktop.Notifications': timed out (service_start_timeout=120000ms)
In this example, the startup attempt was triggered with
notify-send test
(which hangs until the timeout) but I've also seen this triggered by other activity.
These are fairly ordinary buster systems, with (in particular) libgtk-3-0 version 3.24.5-1.
systemd-cgls shows this dbus-daemon as running as part of dbus.service in the user slice, with the following arguments:
/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
I believe this to be normal (I didn't tweak the configuration in this respect) but wonder how daemons in the user slice are supposed to choose between the displays of the user's various active sessions. Still, this bug report is specifically about xfce4-notifyd not handling this more gracefully (e.g., by just going into headless, do-not-disturb mode if no sensible screen can be found; or at the very least by bailing out quickly and quietly rather than after two minutes), not about the flaws of dbus-daemon or systemd (or possibly ssh, if one thinks D-Bus should be forwarded).
Reply to: