Change:
Describe the bug xfce4-notifyd is not started by dbus in 20.09 This is verifiable by checking or just To Reproduce Add xfce.xfce4-notifyd to systemPackages and cause a dbus restart. This seems to be a regression between 20.03 and 20.09 (I don't have proof of this, but I'm confident this all worked before I upgraded to 20.09). Expected behavior That xfce4-notifyd gets picked up by dbus as per Notify maintainers Metadata Maintainer information:
Updated channel, problem still appears. I also see the following message in the dbus-daemon journal:
No idea why I'm seeing those errors at all. does not contain xfce4-notifyd as it should.
Interestingly, if I explicitly put in the /etc/dbus- contains the right reference, but dbus still cant start the notifyd service:
If xfce4-notifyd is explicitly to dbus.packages, there's an appropriate file in the system:
For other users stumbling on this, as a temporary workaround I'm running xfce4-notifyd from my
I updated from 20.03 to 20.09 yesterday without any configuration changes and I got hit with the same problem. Here's my metadata (Yes, I'm also using lambda as shell prompt :smile:) Also, I'm running xfce as DM () + Xmonad as WM. As a workaround I created a systemd user service for xfce4-notifyd: And then in my : Since I didn't restart my graphical session I just started it manually the first time:
Caution: when xfce4-notifyd is down, you may hit a severe which I've reported upstream in that link.
Thanks, I haven't tried this method to make a systemd service before. Is there a way to restrict this to just xfce4 sessions?
Also, has anyone tracked down the change that introduced the issue?
I don't think there's a streamlined way to do this, as is used for all different session types. Maybe you could change to only run when the environment variable contain .
I marked this as stale due to inactivity. &rarr;
I just looked at it again and think I found the immediate problem. xfce4-notifyd no longer carries the dbus-1 directories around in the share directory. So this appears to be a regression at some point in 2020. You seem to have bumped the package and done quite a bit work on xfce. Do you know what could be the cause or a fix here?
The following configure option is available: We can try to enable it and see if it works for you. Note that the default (autostart session) works for me with the default NixOS configuration for Xfce.
Thanks! The autostart file is indeed correctly provided, but that only helps if ones WM/DE is XDG Autostart compliant. Xmonad is not, which is why I was affected, other environments might also lack XDG Autostart. Given the pull request I managed to track down the regression: As for everyone else, the linked PR is a permanent fix. Autostart users should not be affected. The following is a morally correct workaround until the PR hits a nix channel in case any other users are affected by this and don't want to wait. Once PR is merged I will close this issue.
Nice workaround! Much cleaner than the one I suggested :+1:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
<del> { mkXfceDerivation, glib, exo, gtk3, libnotify, libxfce4ui, libxfce4util </del> <ins> { mkXfceDerivation, glib, gtk3, libnotify, libxfce4ui, libxfce4util </ins> , xfce4-panel, xfconf }: mkXfceDerivation {

sha256 = "sha256-Gomehef68+mOgGFDaH48jG51nbaV4ruN925h71w7FuE="; <del> buildInputs = [ exo gtk3 glib libnotify libxfce4ui libxfce4util xfce4-panel xfconf ]; </del> <ins> buildInputs = [ gtk3 glib libnotify libxfce4ui libxfce4util xfce4-panel xfconf ]; configureFlags = [ "--enable-dbus-start-daemon" ]; </ins> meta = { description = "Simple notification daemon for Xfce";