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).
