Discussion:
[arch-general] xfce4-notifyd issues
David Rosenstrauch
2017-06-21 02:10:12 UTC
Permalink
Seems like some recent package update has either caused xfce4-notifyd to
not autostart or to crash after starting. Anyone else seeing this,
and/or have any idea what might be the cause?

Thanks,

DR
David Rosenstrauch
2017-06-21 02:55:01 UTC
Permalink
Post by David Rosenstrauch
Seems like some recent package update has either caused xfce4-notifyd to
not autostart or to crash after starting. Anyone else seeing this,
and/or have any idea what might be the cause?
Not sure if it's having autostart issues, but it definitely seems to be
crashing for some reason:

[***@darosedm ~]$ ps ax | grep notify
3168 pts/1 S+ 0:00 grep notify
[***@darosedm ~]$ systemctl --user start xfce4-notifyd.service
[***@darosedm ~]$ ps ax | grep notify
3173 ? Ssl 0:00 /usr/lib/xfce4/notifyd/xfce4-notifyd
3179 pts/1 S+ 0:00 grep notify
[***@darosedm ~]$ date
Tue Jun 20 22:32:49 EDT 2017


[***@darosedm ~]$ ps ax | grep notify
3511 pts/1 S+ 0:00 grep notify
[***@darosedm ~]$ date
Tue Jun 20 22:51:28 EDT 2017


Anyone have any idea what's happening - or how to debug? I don't see
anything in the messages.log.

Thanks,

DR
David Barri via arch-general
2017-06-21 12:17:37 UTC
Permalink
Broke for me recently too. I had to add this to my .xinitrc:

systemctl --user start xfce4-notifyd.service
David Rosenstrauch
2017-06-21 14:13:41 UTC
Permalink
Post by David Rosenstrauch
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
Paul Franke
2017-06-25 13:03:56 UTC
Permalink
Post by David Rosenstrauch
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.
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.
David Rosenstrauch
2017-06-26 14:35:57 UTC
Permalink
Post by Paul Franke
Post by David Rosenstrauch
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.
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
Bjoern Franke
2017-06-21 19:07:33 UTC
Permalink
Post by David Rosenstrauch
systemctl --user start xfce4-notifyd.service
Which DE are you using? With XFCE, it's autostarted here, not need for
systemctl --user.

Regards
Bjoern
David Rosenstrauch
2017-06-21 19:16:41 UTC
Permalink
Post by Bjoern Franke
Post by David Rosenstrauch
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
Mauro Santos via arch-general
2017-06-21 21:41:52 UTC
Permalink
Post by David Rosenstrauch
Post by Bjoern Franke
Post by David Rosenstrauch
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.
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
Jun 21 15:08:16 darosedm dbus-daemon[628]: Activating service
name='org.freedesktop.Notifications'
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.
--
Mauro Santos
David Rosenstrauch
2017-06-23 01:52:28 UTC
Permalink
Post by Mauro Santos via arch-general
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.
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
Vladimir Lomov via arch-general
2017-06-23 07:53:22 UTC
Permalink
Hello,
Post by David Rosenstrauch
Post by Mauro Santos via arch-general
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.
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.
Post by David Rosenstrauch
Thanks,
DR
---
WBR. Vladimir Lomov
--
"Gort, klaatu nikto barada."
-- The Day the Earth Stood Still
David Rosenstrauch
2017-06-23 13:27:41 UTC
Permalink
Post by Vladimir Lomov via arch-general
Post by David Rosenstrauch
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
Vladimir Lomov via arch-general
2017-06-23 14:57:35 UTC
Permalink
Hello,
Post by Vladimir Lomov via arch-general
Post by David Rosenstrauch
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
--
When women kiss it always reminds one of prize fighters shaking hands.
-- H.L. Mencken, "Sententiae"
David Rosenstrauch
2017-06-23 20:58:38 UTC
Permalink
Post by David Rosenstrauch
Post by Vladimir Lomov via arch-general
Post by David Rosenstrauch
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
Jérôme M. Berger
2017-06-24 06:30:02 UTC
Permalink
Post by David Rosenstrauch
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service
name='org.freedesktop.Notifications'
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
--
mailto:***@free.fr
http://jeberger.free.fr
Diaspora*: https://framasphere.org/u/jeberger
L. Rose
2017-06-24 09:50:03 UTC
Permalink
Post by Jérôme M. Berger
Post by David Rosenstrauch
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service
name='org.freedesktop.Notifications'
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.
David Rosenstrauch
2017-06-26 14:32:17 UTC
Permalink
Post by Jérôme M. Berger
Post by David Rosenstrauch
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service
name='org.freedesktop.Notifications'
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:

[***@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
Jérôme M. Berger
2017-06-26 16:22:29 UTC
Permalink
Post by David Rosenstrauch
My guess is because I have many KDE packages installed, even though I'm
not running KDE. (My DE is XFCE.)
grep org.freedesktop.Notifications -r /usr/share/dbus-1/services
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
--
mailto:***@free.fr
http://jeberger.free.fr
Diaspora*: https://framasphere.org/u/jeberger
David Rosenstrauch
2017-06-26 16:30:32 UTC
Permalink
Post by Jérôme M. Berger
Post by David Rosenstrauch
My guess is because I have many KDE packages installed, even though I'm
not running KDE. (My DE is XFCE.)
grep org.freedesktop.Notifications -r /usr/share/dbus-1/services
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
Jérôme M. Berger
2017-06-26 17:32:04 UTC
Permalink
Post by David Rosenstrauch
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
--
mailto:***@free.fr
http://jeberger.free.fr
Diaspora*: https://framasphere.org/u/jeberger
David Rosenstrauch
2017-06-26 18:19:25 UTC
Permalink
Post by Jérôme M. Berger
Post by David Rosenstrauch
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
Guus Snijders via arch-general
2017-06-26 19:56:05 UTC
Permalink
This post might be inappropriate. Click to display it.
David Rosenstrauch
2017-06-26 20:32:26 UTC
Permalink
Post by Guus Snijders via arch-general
Post by David Rosenstrauch
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
Guus Snijders via arch-general
2017-06-26 20:58:30 UTC
Permalink
Post by Guus Snijders via arch-general
[...]
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
David Rosenstrauch
2017-06-27 01:09:17 UTC
Permalink
Post by Guus Snijders via arch-general
Post by Guus Snijders via arch-general
[...]
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
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

David Rosenstrauch
2017-06-26 16:07:08 UTC
Permalink
Post by David Rosenstrauch
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
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service
name='org.freedesktop.Notifications'
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
Ben Mezger
2017-06-26 16:36:07 UTC
Permalink
Post by David Rosenstrauch
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
--
- seds
~> https://seds.nl
David Rosenstrauch
2017-06-26 16:23:23 UTC
Permalink
Post by David Rosenstrauch
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
Jun 23 16:55:27 darosedm dbus-daemon[723]: Activating service
name='org.freedesktop.Notifications'
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
Loading...