Broke for me recently too. I had to add this to my .xinitrc:
systemctl --user start xfce4-notifyd.service
On 06/21/2017 08:17 AM, David Barri via arch-general wrote:
Broke for me recently too. I had to add this to my .xinitrc:
systemctl --user start xfce4-notifyd.service
1) Any idea what's responsible?
2) From what I can see the issue isn't just startup. If you see my previous email, it looks like the notifyd is crashing for some reason.
DR
Any idea what's responsible?
From what I can see the issue isn't just startup. If you see my
previous email, it looks like the notifyd is crashing for some reason.
Maybe, xfce4-notifyd crashes on startup due to not set DISPLAY environment variable?
Please, check for DISPLAY using: dbus-update-activation-environment --verbose --all
If not, make sure /etc/X11/xinit/xinitrc.d/50-systemd-user.sh gets sourced on startup of Xorg in some way.
On 06/25/2017 09:03 AM, Paul Franke wrote:
Any idea what's responsible?
From what I can see the issue isn't just startup. If you see my
previous email, it looks like the notifyd is crashing for some reason.
Maybe, xfce4-notifyd crashes on startup due to not set DISPLAY environment variable?
Please, check for DISPLAY using: dbus-update-activation-environment --verbose --all
If not, make sure /etc/X11/xinit/xinitrc.d/50-systemd-user.sh gets sourced on startup of Xorg in some way.
I've come to the conclusion that xfce4-notifyd isn't crashing on startup, but rather it's intentionally shutting down on inactivity. (See https://bugzilla.xfce.org/show_bug.cgi?id=12754) And the problem isn't that it's shutting down, but rather that it's not able to successfully restart itself.
The DISPLAY variable does seem to be getting set correctly in my console sessions:
$ dbus-update-activation-environment --verbose --all 2>&1 | grep DISPLAY dbus-update-activation-environment: setting DISPLAY=:0.0
But perhaps it's not getting set for non-interactive/non-login sessions somehow. I'll look into that.
Thanks,
DR
Am 21.06.2017 um 14:17 schrieb David Barri via arch-general:
Broke for me recently too. I had to add this to my .xinitrc:
systemctl --user start xfce4-notifyd.service
Which DE are you using? With XFCE, it's autostarted here, not need for systemctl --user.
Regards Bjoern
On 06/21/2017 03:07 PM, Bjoern Franke wrote:
Am 21.06.2017 um 14:17 schrieb David Barri via arch-general:
Broke for me recently too. I had to add this to my .xinitrc:
systemctl --user start xfce4-notifyd.service
Which DE are you using? With XFCE, it's autostarted here, not need for systemctl --user.
Regards Bjoern
I (the original reporter) am running XFCE.
I've done a bit of research on the issue. Seems like what's happening is:
a) Apparently xfce4-notifyd intentionally (!) shuts itself down after 10 mins of inactivity (see https://bugzilla.xfce.org/show_bug.cgi?id=12754). However, it's had this behavior for quite some time (since v0.3.0 - we're now at 0.3.6), so I don't think this is the source of the issue.
b) It looks like what changed recently is that for some reason dbus is no longer able to automatically restart xfce4-notifyd when a notification happens. See what I get when I issue "notify-send 'test'":
Jun 21 15:08:16 darosedm dbus-daemon[628]: Activating service name='org.freedesktop.Notifications' Jun 21 15:09:16 darosedm plasma_waitforname[7097]: org.kde.knotifications: WaitForName: Service was not registered within timeout Jun 21 15:09:16 darosedm dbus-daemon[628]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
I haven't quite pinned down what's causing the restart to fail yet. If anyone has any relevant info, please do share.
Thanks,
DR
On 21-06-2017 20:16, David Rosenstrauch wrote:
On 06/21/2017 03:07 PM, Bjoern Franke wrote:
Am 21.06.2017 um 14:17 schrieb David Barri via arch-general:
Broke for me recently too. I had to add this to my .xinitrc:
systemctl --user start xfce4-notifyd.service
Which DE are you using? With XFCE, it's autostarted here, not need for systemctl --user.
Regards Bjoern
I (the original reporter) am running XFCE.
I've done a bit of research on the issue. Seems like what's happening is:
a) Apparently xfce4-notifyd intentionally (!) shuts itself down after 10 mins of inactivity (see https://bugzilla.xfce.org/show_bug.cgi?id=12754). However, it's had this behavior for quite some time (since v0.3.0 - we're now at 0.3.6), so I don't think this is the source of the issue.
b) It looks like what changed recently is that for some reason dbus is no longer able to automatically restart xfce4-notifyd when a notification happens. See what I get when I issue "notify-send 'test'":
Jun 21 15:08:16 darosedm dbus-daemon[628]: Activating service name='org.freedesktop.Notifications' Jun 21 15:09:16 darosedm plasma_waitforname[7097]: org.kde.knotifications: WaitForName: Service was not registered within timeout Jun 21 15:09:16 darosedm dbus-daemon[628]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
I haven't quite pinned down what's causing the restart to fail yet. If anyone has any relevant info, please do share.
It's working fine here.
I don't use a login manager, I login from a tty and I haven't changed any configuration in a long while. I also don't do anything special to launch xfce or anything else.
my .xinitrc has:
if [ -d /etc/X11/xinit/xinitrc.d ]; then for f in /etc/X11/xinit/xinitrc.d/*; do [ -x "$f" ] && . "$f" done unset f fi exec startxfce4
and that's all.
On 06/21/2017 05:41 PM, Mauro Santos via arch-general wrote:
It's working fine here.
I don't use a login manager, I login from a tty and I haven't changed any configuration in a long while. I also don't do anything special to launch xfce or anything else.
my .xinitrc has:
if [ -d /etc/X11/xinit/xinitrc.d ]; then for f in /etc/X11/xinit/xinitrc.d/*; do [ -x "$f" ] && . "$f" done unset f fi exec startxfce4
and that's all.
Useful data point - thanks. I am using a login manager (lightdm), which launches startxfce4. Perhaps there's something got messed up with that combination.
Thanks,
DR
Hello, ** David Rosenstrauch [2017-06-22 21:52:28 -0400]:
On 06/21/2017 05:41 PM, Mauro Santos via arch-general wrote:
It's working fine here.
I don't use a login manager, I login from a tty and I haven't changed any configuration in a long while. I also don't do anything special to launch xfce or anything else.
my .xinitrc has:
if [ -d /etc/X11/xinit/xinitrc.d ]; then for f in /etc/X11/xinit/xinitrc.d/*; do [ -x "$f" ] && . "$f" done unset f fi exec startxfce4
and that's all.
Useful data point - thanks. I am using a login manager (lightdm), which launches startxfce4. Perhaps there's something got messed up with that combination.
Try sddm.
Thanks,
DR
--- WBR. Vladimir Lomov
On 06/23/2017 03:53 AM, Vladimir Lomov via arch-general wrote:
** David Rosenstrauch [2017-06-22 21:52:28 -0400]:
Useful data point - thanks. I am using a login manager (lightdm), which launches startxfce4. Perhaps there's something got messed up with that combination.
Try sddm.
Perhaps. To be honest, I don't think lightdm is responsible for the issue either. (It hasn't been updated since March.) There's obviously *something* that changed recently that's causing this behavior. I'm not sure what - or how to fix. But there's some evidence this might get fixed on the XFCE side soon.
Thanks,
DR
Hello, ** David Rosenstrauch [2017-06-23 09:27:41 -0400]:
On 06/23/2017 03:53 AM, Vladimir Lomov via arch-general wrote:
** David Rosenstrauch [2017-06-22 21:52:28 -0400]:
Useful data point - thanks. I am using a login manager (lightdm), which launches startxfce4. Perhaps there's something got messed up with that combination.
Try sddm.
Perhaps. To be honest, I don't think lightdm is responsible for the issue either. (It hasn't been updated since March.) There's obviously *something* that changed recently that's causing this behavior. I'm not sure what - or how to fix. But there's some evidence this might get fixed on the XFCE side soon.
I used to use lightdm for some time but from time to time I faced with very *strange* message from various programs about connection to dbus (they refered to /tmp/dbus-XXXXX, saying "Connection failed" or something like that, but dbus is started by systemd and it's socket is in /run NOT in /tmp). I tried to investigate this problem but without any success.
Moreover, I found some problem with how lightdm initialize session (I don't remember details, though I filed a bug report for that) but AFAIU it wasn't fixed. I switched to sddm and don't see any more any messages about dbus in /tmp.
Thanks,
DR
--- WBR, Vladimir Lomov
On 06/23/2017 09:27 AM, David Rosenstrauch wrote:
On 06/23/2017 03:53 AM, Vladimir Lomov via arch-general wrote:
** David Rosenstrauch [2017-06-22 21:52:28 -0400]:
Useful data point - thanks. I am using a login manager (lightdm), which launches startxfce4. Perhaps there's something got messed up with that combination.
Try sddm.
Perhaps. To be honest, I don't think lightdm is responsible for the issue either. (It hasn't been updated since March.) There's obviously *something* that changed recently that's causing this behavior. I'm not sure what - or how to fix. But there's some evidence this might get fixed on the XFCE side soon.
FYI, I just tested under sddm and I still see the same issue. For whatever reason, xfce4-notifyd does not get started in response to attempts to launch service 'org.freedesktop.Notifications':
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout Jun 23 16:56:27 darosedm dbus-daemon[723]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
DR
On 06/23/2017 10:58 PM, David Rosenstrauch wrote:
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Why does it say that it is waiting for org.*kde*.knotifications and not org.freedesktop.Notifications? I'm betting there is some kind of configuration conflict between knotifyd and xfce-notifyd. I would grep for those two strings inside /usr/share/dbus-1/services to check if there is not a stale service file causing the trouble.
Jerome
Am 24.06.2017 um 08:30 schrieb Jérôme M. Berger:
On 06/23/2017 10:58 PM, David Rosenstrauch wrote:
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Why does it say that it is waiting for org.*kde*.knotifications and not org.freedesktop.Notifications? I'm betting there is some kind of configuration conflict between knotifyd and xfce-notifyd. I would grep for those two strings inside /usr/share/dbus-1/services to check if there is not a stale service file causing the trouble.
Jerome
I'm using xfce4 with lightdm, everything working fine here.
On 06/24/2017 02:30 AM, Jérôme M. Berger wrote:
On 06/23/2017 10:58 PM, David Rosenstrauch wrote:
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout
Why does it say that it is waiting for org.*kde*.knotifications and not org.freedesktop.Notifications? I'm betting there is some kind of configuration conflict between knotifyd and xfce-notifyd. I would grep for those two strings inside /usr/share/dbus-1/services to check if there is not a stale service file causing the trouble.
Jerome
My guess is because I have many KDE packages installed, even though I'm not running KDE. (My DE is XFCE.)
I did that grep, but didn't see anything suspicious:
[darose@darosedm services]$ find . -type f | xargs grep notify ./org.kde.knotify.service:Name=org.kde.knotify ./org.kde.knotify.service:Exec=/usr/bin/knotify4 ./org.xfce.xfce4-notifyd.Notifications.service:Exec=/usr/lib/xfce4/notifyd/xfce4-notifyd ./org.xfce.xfce4-notifyd.Notifications.service:SystemdService=xfce4-notifyd.service
Thanks,
DR
On 06/26/2017 04:32 PM, David Rosenstrauch wrote:
My guess is because I have many KDE packages installed, even though I'm not running KDE. (My DE is XFCE.)
I did that grep, but didn't see anything suspicious:
[darose@darosedm services]$ find . -type f | xargs grep notify
Wrong grep. Try:
grep org.freedesktop.Notifications -r /usr/share/dbus-1/services
and especially:
grep org.kde.knotifications -r /usr/share/dbus-1/services
The second one in particular should not return anything but I'm betting in your case it will...
Jerome
On 06/26/2017 12:22 PM, Jérôme M. Berger wrote:
On 06/26/2017 04:32 PM, David Rosenstrauch wrote:
My guess is because I have many KDE packages installed, even though I'm not running KDE. (My DE is XFCE.)
I did that grep, but didn't see anything suspicious:
[darose@darosedm services]$ find . -type f | xargs grep notify
Wrong grep. Try:
grep org.freedesktop.Notifications -r /usr/share/dbus-1/services
and especially:
grep org.kde.knotifications -r /usr/share/dbus-1/services
The second one in particular should not return anything but I'm betting in your case it will...
Yes, you're correct:
$ grep org.freedesktop.Notifications -r /usr/share/dbus-1/services /usr/share/dbus-1/services/org.kde.plasma.Notifications.service:Name=org.freedesktop.Notifications /usr/share/dbus-1/services/org.kde.plasma.Notifications.service:Exec=/usr/bin/plasma_waitforname org.freedesktop.Notifications /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service:Name=org.freedesktop.Notifications
Any idea how to resolve the conflict between these 2 notification services? (Without being forced to remove half of KDE?)
For example, dbus seems to be selecting the kde plasma notification service to respond to the org.freedesktop.Notifications service messages, rather than the XFCE one. Would you know if there's a way to disable the plasma service, or tell dbus that the xfce one should have a higher priority?
Thanks,
DR
Thanks,
DR
On 06/26/2017 06:30 PM, David Rosenstrauch wrote:
Any idea how to resolve the conflict between these 2 notification services? (Without being forced to remove half of KDE?)
For example, dbus seems to be selecting the kde plasma notification service to respond to the org.freedesktop.Notifications service messages, rather than the XFCE one. Would you know if there's a way to disable the plasma service, or tell dbus that the xfce one should have a higher priority?
I'm not sure, but it looks like dbus is selecting the first one in alphabetic order (here it chooses org.freedesktop.mate.Notifications.service over org.kde.plasma.Notifications.service). I don't know if there is a way to specify a per-user override, but I would guess that symlinking /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service to /usr/share/dbus-1/services/00.org.freedesktop.Notifications.service (or some similar name that comes before kde) has a fair chance of solving the issue for you...
Jerome
On 06/26/2017 01:32 PM, Jérôme M. Berger wrote:
On 06/26/2017 06:30 PM, David Rosenstrauch wrote:
Any idea how to resolve the conflict between these 2 notification services? (Without being forced to remove half of KDE?)
For example, dbus seems to be selecting the kde plasma notification service to respond to the org.freedesktop.Notifications service messages, rather than the XFCE one. Would you know if there's a way to disable the plasma service, or tell dbus that the xfce one should have a higher priority?
I'm not sure, but it looks like dbus is selecting the first one in alphabetic order (here it chooses org.freedesktop.mate.Notifications.service over org.kde.plasma.Notifications.service). I don't know if there is a way to specify a per-user override, but I would guess that symlinking /usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service to /usr/share/dbus-1/services/00.org.freedesktop.Notifications.service (or some similar name that comes before kde) has a fair chance of solving the issue for you...
Jerome
Thanks much for the assistance.
I tried the symlink approach, but it didn't seem to work.
I opened up a bug at KDE about this, if anyone's interested. (https://bugs.kde.org/show_bug.cgi?id=381693) Perhaps they'll have some suggestions for workarounds (or a fix).
Thanks,
DR
Op 26 jun. 2017 20:19 schreef "David Rosenstrauch" darose@darose.net:
On 06/26/2017 01:32 PM, Jérôme M. Berger wrote:
On 06/26/2017 06:30 PM, David Rosenstrauch wrote:
Any idea how to resolve the conflict between these 2 notification services? (Without being forced to remove half of KDE?)
A fair bit of searching gave this result; https://askubuntu.com/questions/843076/how-to-blacklist-a-d-bus-service
In short: they use dbus permissions for blacklisting.
Although I really dislike editing in /usr, perhaps the same thing can be realised in /etc/somewhere (don't have an Arch Linux install handy ATM).
A deny policy (on the KDE notification) for your user should solve the problem without hacking through dependencies.
Mvg, Guus Snijders
On 06/26/2017 03:56 PM, Guus Snijders via arch-general wrote:
Op 26 jun. 2017 20:19 schreef "David Rosenstrauch" darose@darose.net:
On 06/26/2017 01:32 PM, Jérôme M. Berger wrote:
On 06/26/2017 06:30 PM, David Rosenstrauch wrote:
Any idea how to resolve the conflict between these 2 notification services? (Without being forced to remove half of KDE?)
A fair bit of searching gave this result; https://askubuntu.com/questions/843076/how-to-blacklist-a-d-bus-service
In short: they use dbus permissions for blacklisting.
Although I really dislike editing in /usr, perhaps the same thing can be realised in /etc/somewhere (don't have an Arch Linux install handy ATM).
A deny policy (on the KDE notification) for your user should solve the problem without hacking through dependencies.
Thanks for the suggestion. I tried to fix this as per your suggestion but wasn't able to make it work:
$ cat /etc/dbus-1/session-local.conf <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"> <busconfig> <policy context="default"> <deny send_destination="org.kde.knotifications"/> </policy> </busconfig>
For now, I've worked around the issue by commenting out the contents of /usr/share/dbus-1/services/org.kde.plasma.Notifications.service . But this really ought to be fixed upstream by one or more of the following:
1) xfce4-notifyd shouldn't shut itself down on inactivity 2) KDE should do something to remove the conflict between their new notifications dbus file and those belonging to other DE's
There's bugs open for both of these. I'll see how upstream wants to handle them.
Thanks,
DR
Op 26 jun. 2017 22:32 schreef "David Rosenstrauch" darose@darose.net:
On 06/26/2017 03:56 PM, Guus Snijders via arch-general wrote:
[...] In short: they use dbus permissions for blacklisting. [...]
A deny policy (on the KDE notification) for your user should solve the problem without hacking through dependencies.
Thanks for the suggestion. I tried to fix this as per your suggestion but wasn't able to make it work:
Probably a stupid question, but you did restart dbus after editing, right?
[...] For now, I've worked around the issue by commenting out the contents of /usr/share/dbus-1/services/org.kde.plasma.Notifications.service . But this really ought to be fixed upstream by one or more of the following:
1) xfce4-notifyd shouldn't shut itself down on inactivity 2) KDE should do something to remove the conflict between their new notifications dbus file and those belonging to other DE's
There's bugs open for both of these. I'll see how upstream wants to handle them.
Looks to me like the problem is with dbus itself; there doesn't appear to be a way to let the *user* choose which applications to start for $action.
I like working with policies, but on a flexible system like Linux, the user should have the last word, IMHO.
Mvg, Guus Snijders
On 06/26/2017 04:58 PM, Guus Snijders via arch-general wrote:
Op 26 jun. 2017 22:32 schreef "David Rosenstrauch" darose@darose.net:
On 06/26/2017 03:56 PM, Guus Snijders via arch-general wrote:
[...] In short: they use dbus permissions for blacklisting. [...]
A deny policy (on the KDE notification) for your user should solve the problem without hacking through dependencies.
Thanks for the suggestion. I tried to fix this as per your suggestion but wasn't able to make it work:
Probably a stupid question, but you did restart dbus after editing, right?
I did ... and it killed my X session! :-( (And didn't seem to fix the problem.)
DR
On 06/23/2017 04:58 PM, David Rosenstrauch wrote:
FYI, I just tested under sddm and I still see the same issue. For whatever reason, xfce4-notifyd does not get started in response to attempts to launch service 'org.freedesktop.Notifications':
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout Jun 23 16:56:27 darosedm dbus-daemon[723]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
Does anyone know how I might go about debugging how/why this failure is happening?
Jun 23 16:56:27 darosedm dbus-daemon[723]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
Is there some way to enable more detailed logging in dbus?
Thanks,
DR
On 06/26/2017 01:07 PM, David Rosenstrauch wrote:
Is there some way to enable more detailed logging in dbus?
d-feet [0] makes it debugging Dbus easier. It can be used to inspect Dbus interface of running programs and invoke methods on those interfaces.
Ubuntu's wiki has a more ugly way of debugging it [1].
[0] - https://www.archlinux.org/packages/?name=d-feet [1] - https://wiki.ubuntu.com/DebuggingDBus
On 06/23/2017 04:58 PM, David Rosenstrauch wrote:
FYI, I just tested under sddm and I still see the same issue. For whatever reason, xfce4-notifyd does not get started in response to attempts to launch service 'org.freedesktop.Notifications':
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service name='org.freedesktop.Notifications' Jun 23 16:56:27 darosedm plasma_waitforname[1988]: org.kde.knotifications: WaitForName: Service was not registered within timeout Jun 23 16:56:27 darosedm dbus-daemon[723]: Activated service 'org.freedesktop.Notifications' failed: Process org.freedesktop.Notifications exited with status 1
I finally see what happened. The file "/usr/share/dbus-1/services/org.kde.plasma.Notifications.service", provided by package plasma-workspace is new, and is conflicting with file org.xfce.xfce4-notifyd.Notifications.service. When I move it out of the way, xfce4-notifyd launches properly:
Jun 26 12:19:31 darosedm dbus-daemon[640]: Activating via systemd: service name='org.freedesktop.Notifications' unit='xfce4-notifyd.service' Jun 26 12:19:31 darosedm systemd[614]: Starting XFCE notifications service... Jun 26 12:19:31 darosedm dbus-daemon[640]: Successfully activated service 'org.freedesktop.Notifications' Jun 26 12:19:31 darosedm systemd[614]: Started XFCE notifications service. Jun 26 12:20:12 darosedm dbus-daemon[640]: Reloaded configuration
Now I just need to figure out how to resolve the conflict.
DR
arch-general@lists.archlinux.org