Some minutes after being started, xfce4-notifyd always terminates silently, without any error message or core dump and without any external influence (don't know why). This happens both when started by the xfce session startup and when started on the commandline of an xfce terminal. Now, when a notification is to be displayed after xfce4-notifyd terminated, dbus tries to restart xfce4-notifyd, but that fails. From the systemd journal: Aug 10 19:18:25 lap dbus-daemon[353]: Activating via systemd: service name='org.freedesktop.Notifications' unit='xfce4-notifyd.service' Aug 10 19:18:25 lap systemd[334]: Starting XFCE notifications service... Aug 10 19:18:25 lap xfce4-notifyd[976]: (xfce4-notifyd:976): Gtk-WARNING **: cannot open display: Aug 10 19:18:25 lap systemd[334]: xfce4-notifyd.service: Main process exited, code=exited, status=1/FAILURE Aug 10 19:18:25 lap systemd[334]: Failed to start XFCE notifications service. Aug 10 19:18:25 lap systemd[334]: xfce4-notifyd.service: Unit entered failed state. Aug 10 19:18:25 lap systemd[334]: xfce4-notifyd.service: Failed with result 'exit-code'. The result is quite fatal: The applications which tried to send the notifications (in my case, usually the mail program, same for the xfce4-notifyd-config test message) hang infinitely until being killed. I think the error message from xfce4-notifyd about "cannot open display" is technically correct: I start X the clean way, logging into a vt in text mode and then startig X within the same systemd session from the text terminal session. Hence, as far as I can tell, the user systemd process and the session dbus process seem to be started by login *before* I start X and consequently do not have any X environment, i.e. no DISPLAY.
Hi, Xfce-notifyd 0.3.0 with systemd and lightdm on Arch Linux here. Notifyd works as expeted. Can't reproduce. BR killermoehre
It might help to tell what kind of system (distribution, version etc.) you're seeing that behavior on. Could it be related to the “deprecation” of dbus-launch and the way the systems have to start / interact with the dbus daemon? See for example the xfce4-session bug (https://bugzilla.xfce.org/show_bug.cgi?id=12801) and the various links posted there.
System is Gentoo, but I'm quite sure this does not matter. What matters is the way the session is started, or more exactly when systemd starts the user's dbus daemon (the dbus daemon is started when systemd starts a new user session): On my system, I log into a traditional virtual terminal (in text mode) and then start X from within that textmode session, replacing the original text mode screen with X within the *same* virtual terminal (consequently, from systemd's point of view, X belongs to the original text mode session and does *not* start a new session). I don't know what the current situation is, but starting X in this way within a vt session originally was the first and only way to run the X server with user priviledges instead of root priviledges, i.e. the safest way to run X. In this configuration, the dbus daemon is started during text login, before X is started, and hence does not have any X environment variables (which also means that any programs started by dbus do not have a valid X environment, especially no DISPLAY and no XAUTHORITY). In comment #1, a graphical login manager is used, hence the systemd session and dbus daemon is started by the login manager or by the X server, *after* setting up a complete X environment, hence the problem does not occur. But independent of the dbus problem: What's the reason for terminating notifyd after 10 minutes and having it restarted by dbus at the next message? Letting notifyd just run all the time looks much simpler and more efficient to me?
I can confirm this bug. I am running arch with a kernel version 4.7.2-1 and xfce4-notifyd version 0.3.2-1. The bug first occured when I switched from lightdm to starting X with startx directly from tty1.
Archlinux comes with an xinit script (see [1]) to setup DISPLAY and XAUTHORITY. The /etc/X11/xinit/xinitrc sources all of the scripts located in the xinitrc.d directory. My user config i.e., ~/.xinitrc did not source the script 50-systemd-user.sh and thereby cause this error. Solution: Either make changes directly in the system-wide config /etc/X11/xinitrc which already sources 50-systemd-user.sh or copying the relevant parts to your user's rc. [1] https://wiki.archlinux.org/index.php/Systemd/User#DISPLAY_and_XAUTHORITY
(In reply to simon from comment #5) > Archlinux comes with an xinit script (see [1]) to setup DISPLAY and > XAUTHORITY. > The /etc/X11/xinit/xinitrc sources all of the scripts located in the > xinitrc.d directory. > My user config i.e., ~/.xinitrc did not source the script 50-systemd-user.sh > and thereby cause this error. > > Solution: > Either make changes directly in the system-wide config /etc/X11/xinitrc > which already sources 50-systemd-user.sh or copying the relevant parts to > your user's rc. > > [1] https://wiki.archlinux.org/index.php/Systemd/User#DISPLAY_and_XAUTHORITY That seems to solve the problem, but still the basic question in #3 remains: What's the reason for terminating notifyd after 10 minutes and having it restarted by dbus at the next message? Letting notifyd just run all the time looks much simpler and more efficient to me?
@Klaus Kusche: This behavior has always been there. notifyd 0.2.4 also had this timeout to shut down after 10mins of no activity/notifications. If you would want to know the real reason you would have to get in touch with Jerome who designed xfce4-notifyd to see why he thought this is for the best. For the moment I don't plan to change this behavior.
Following the suggestion of @simon adding the line: . /etc/X11/xinit/xinitrc.d/50-systemd-user.sh to ~/.xinitrc solved this issue for me on Arch. I feel it is worth mentioning that when xfce4-notifyd is not running it causes strange issues with various desktop clients. For instance, the official Slack client for Linux becomes completely unresponsive. Wicd Network Manager appears to be frozen as well.
(In reply to Kevin Schoon from comment #8) > Following the suggestion of @simon adding the line: > . /etc/X11/xinit/xinitrc.d/50-systemd-user.sh > to ~/.xinitrc solved this issue for me on Arch. > > I feel it is worth mentioning that when xfce4-notifyd is not running it > causes strange issues with various desktop clients. For instance, the > official Slack client for Linux becomes completely unresponsive. Wicd > Network Manager appears to be frozen as well. I think there are two separate problems: 1.) One needs 50-systemd-user.sh if X is started from a tty session. It is generalley needed for all X applications started by dbus, not just for notifyd, and should be mentioned prominently somewhere. 2.) I still see no reason why notifyd goes away and needs to be restarted after 10 minutes of inactivity. Who could provide arguments for that behaviour? Place to discuss this? It should be started at session startup and run as long as the session persists.
I can include a reference to the required .sh file in the readme. Regarding the daemon restarting I don't know why that was initially decided. I can try to patch it out and I guess then I'll have to fix a lot of memory leaks nobody ever noticed before :) In all seriousness, I suggest you submit a separate bugreport about that. Thanks.
The daemon now does not exit anymore after 10mins of inactivity: https://git.xfce.org/apps/xfce4-notifyd/commit/?id=d87a4a93b2ec4ab094f5a35ae818395f750f2891 The other issue is - as you explained well - not related to xfce4-notifyd.
*** Bug 13672 has been marked as a duplicate of this bug. ***
Any idea when this fix might get released in a new version of xfce4-notifyd?