Bug 484945 - D-Bus activation needs a way to prefer one service over the other depending on the running desktop environment
Summary: D-Bus activation needs a way to prefer one service over the other depending o...
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
: 498867 1016828 1499743 (view as bug list)
Depends On:
Blocks: F11Target 519654 806539 1394927
TreeView+ depends on / blocked
Reported: 2009-02-10 19:54 UTC by Kevin Kofler
Modified: 2023-02-16 09:31 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed:
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
FreeDesktop.org 20099 0 'medium' 'RESOLVED' 'ability to add activation directories later' 2019-11-11 12:28:10 UTC

Description Kevin Kofler 2009-02-10 19:54:52 UTC
Description of problem:
Currently, if 2 programs provide the same service, D-Bus activation just picks an arbitrary one:
       /* FIXME we need a better-defined algorithm for which service file to
        * pick than "whichever one is first in the directory listing"

This is a problem in cases like PolicyKit where desktop environments provide their own integration, i.e. PolicyKit-gnome and PolicyKit-kde.

We need a way to have PolicyKit-kde chosen in KDE and PolicyKit-gnome elsewhere automatically. If only one is installed, that one provider should be chosen.

Version-Release number of selected component (if applicable):
(but this has been there ever since D-Bus activation exists and is not fixed in the D-Bus trunk yet either)

How reproducible:

Steps to Reproduce:
1. Install PolicyKit-kde on a system with PolicyKit-gnome already installed.
2. Start KDE.
3. Start KPackageKit.
Actual results:
PolicyKit-gnome starts.

Expected results:
PolicyKit-kde starts.

Additional info:
We'd happily do the required changes in PolicyKit-kde, but we need D-Bus fixed. Or can you suggest a reliable workaround?

Comment 1 Colin Walters 2009-02-10 20:06:05 UTC
Without modifying dbus, this could be handled by using two names.  First the "generic" name which in this case appears to be "org.gnome.PolicyKit", and the "implementation name" which could be org.gnome.PolicyKitGnome.

The desktop environment would be responsible for activating org.gnome.PolicyKitGnome on startup.

This does sort of remove the on-demand nature of things.

Another design is that dbus activation could support *one* "service prefix" which some other process (e.g. gnome-session) sets on it during startup.  During activation of a name org.foo.Bar, it would first try activating prefix/org.foo.Bar.

Comment 2 Kevin Kofler 2009-02-10 20:39:15 UTC
I think the "service prefix" idea sounds like the best solution. How would this be implemented? By sorting the directory list so the services with the prefix come first? (It's an O(n) partial sorting, there just need to be 2 buckets.)

Comment 3 Colin Walters 2009-02-10 20:48:53 UTC
I was thinking of subdirectories, i.e. /usr/share/dbus-1/services/GNOME/

Comment 4 Matthias Clasen 2009-02-13 05:44:17 UTC
Can't you already do that, by having each desktop environment use its own dbus session.conf file, with an additional <servicedir> directive ?

Comment 5 Matthias Clasen 2009-02-13 05:46:58 UTC
I guess it would just be


Comment 6 Kevin Kofler 2009-02-13 08:43:32 UTC
How would we start D-Bus with that session.conf file? Isn't it started from common code for all X sessions? If it's the latter, I think we need to be able to change the settings with a message to a running D-Bus.

As for:
> <include>/etc/dbus-1/session.conf</include>
> <servicedir>/usr/share/dbus-1/services/GNOME</servicedir>
won't that still scan the default search dirs before the one you add there? I think we want the desktop-provided servicedir to take precedence, so we can have one default PolicyKit provider and individual desktop environments can override it. If you put PolicyKit-gnome under GNOME and PolicyKit-kde under KDE, other environments will be left with no PolicyKit support.

Comment 7 Matthias Clasen 2009-02-13 15:24:09 UTC
Yes, you are right, currently the bus is started from

According to the dbus-daemon man page the last specified servicedir is scanned first. Gotta love that...

Comment 8 Kevin Kofler 2009-02-13 15:34:34 UTC
> Yes, you are right, currently the bus is started from
> /etc/X11/xinitrc/xinitrc.d/00-start-message-bus.sh

So that's the problem.
Is there any way we can inject a servicedir into a running D-Bus? If not, should there be one?
Alternatively, startkde can start D-Bus on its own:
> if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
>     eval `dbus-launch --sh-syntax --exit-with-session`
> fi
so maybe we should just have it kill the running D-Bus and restart it with the config file we want?

> According to the dbus-daemon man page the last specified servicedir is scanned
> first. Gotta love that...

Well, in this case it'd actually be what we want.

Comment 9 Colin Walters 2009-02-13 15:55:07 UTC
Filed upstream, feel free to continue there: https://bugs.freedesktop.org/show_bug.cgi?id=20099

Comment 10 Colin Walters 2009-02-13 16:09:14 UTC
Killing the bus is a bad idea because the reason it runs early is to let "early things" use it.

Comment 11 Matthias Clasen 2009-02-13 16:20:05 UTC
Yeah, killing the bus is out of the question

Comment 12 Nils Philippsen 2009-03-02 08:38:38 UTC
Sorry for coming late...

(In reply to comment #1)
> The desktop environment would be responsible for activating
> org.gnome.PolicyKitGnome on startup.

This would lead the whole "service shall be started on demand in order to not waste resources or add to startup time" thing ad absurdum, wouldn't it?

Comment 13 Matthias Clasen 2009-05-04 16:27:50 UTC
*** Bug 498867 has been marked as a duplicate of this bug. ***

Comment 14 Toshio Ernie Kuratomi 2009-05-13 19:10:39 UTC
Note that at the distribution level, we'll need to load all the services (which could be directories for KDE, GNOME, xfce, etc), then when a desktop environment is selected, make the directory for the desktop environment to be searched first.  Otherwise, if a user has a service installed that can satisfy a call to the bus but its the one written for a different desktop environment than they're running, they'll get a failure instead of that service.

Comment 15 Kevin Kofler 2009-05-13 20:42:30 UTC
It's the job of comps to drag in the default packages for each environment, not dependencies. Otherwise we end up with packages requiring KDE, GNOME and XFCE components at the same time.

Comment 16 Toshio Ernie Kuratomi 2009-05-13 21:35:35 UTC
well.. let's say that you're running kde.  But you just like to run a different irc client.  That irc client uses the org.freedesktop.Notifications service.  KDE doesn't provide a server for that; it uses the org.kde.knotify service for its apps.  So you install this alternate irc client and it pulls in a package for org.freedesktop.Notifications.  This happens to be xfce4-notifyd (see the current ml discussions).  So the problem is that if you only register the KDE services for your desktop, the notification service won't be found.

You have to be able to find all the services that can be launched on the system but make the search order changable so that you look for a specific one for your desktop environment first.

Comment 17 Matthias Clasen 2009-05-14 00:50:59 UTC
Nah, kde should just support org.freedesktop.Notifications. 
Problem solved, without any complicated overloaded searchpath schemes.

Comment 18 Kevin Kofler 2009-05-14 00:55:28 UTC
Well, then we'd have 3 notification daemons, how to ensure the right one gets activated? Well, I guess in that case the notification daemon can just run on desktop startup and stay there, bypassing the need for D-Bus activation entirely, but that doesn't solve the problem for those services like PolicyKit which do need D-Bus activation to work properly.

Comment 19 Matthias Clasen 2009-05-14 01:07:36 UTC
FWIW, PolicyKit 1.0 is moving away from autostarting the agent, and having it explicitly started by the session and registered with the service.

Comment 20 Toshio Ernie Kuratomi 2009-05-14 04:04:31 UTC
So... KDE needs to write a daemon so that a gnome or xfce app can display notifications?  Somehow that doesn't make sense to me.

Comment 21 Matthias Clasen 2009-05-14 14:00:30 UTC
org.freedesktop.Notifications is a desktop-neutral api for notifications that can have desktop-specific implementations. if kde doesn't implement it, then apps which use that api for notifications won't show them when running under kde. 
Seems entirely logical to me...

Comment 22 Matthias Clasen 2009-05-14 14:02:26 UTC
One way to 'implement' that api would be to add a service file for the xfce or gnome implementation to the dbus service dir thats used in kde sessions, of course.

Comment 23 Colin Walters 2009-05-14 14:18:42 UTC
This bug is definitely a prime example of the terrifying mess that happens when we try to make lower levels of the software stack pluggable, and to express that as a dependency graph.

Anyways.  I see three categories for the cases here:


1) An install of the 'GNOME Desktop Envionment' comps group, and the LiveCD
2) Ditto for KDE/XFCE

== Ideally would work, if we can ==

1) Running KDE, install xchat which has a plugin which uses org.freedesktop.Notifications

== Don't really care ==

1) You're starting from a server or minimal image, then "yum install xchat"
2) A GNOME install, you decide to "yum groupinstall XFCE" too

Comment 24 Colin Walters 2009-05-14 14:22:23 UTC
My concrete suggestion here is:

* notification-daemon, due to its status as "reference/de-facto" implementation, lives in /usr/share/dbus-1/services/org.freedesktop.Notifications
* We implement the "service prefix" idea for dbus
* XFCE puts xfce4-notifyd in /usr/share/dbus-1/services/XFCE

Comment 25 Colin Walters 2009-05-14 14:55:17 UTC
Matthias, I'm uncomfortable with relying on KDE to handle this.  Really it's XFCE that introduced this mess, and expanding the scope of the conflict from GNOME/XFCE to include KDE means even more complexity.

Comment 26 Rex Dieter 2009-05-14 15:24:35 UTC
If it matters, KDE has interest in supporting a standard Notifications, providing a few details get worked out, for example,

(but that's a bit offtopic for *this* bug/issue)

Comment 27 Bug Zapper 2009-06-09 11:14:31 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:

Comment 28 Rex Dieter 2009-08-27 12:49:30 UTC
*** Bug 519654 has been marked as a duplicate of this bug. ***

Comment 29 Bug Zapper 2010-04-27 12:55:39 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 30 Christoph Wickert 2010-04-27 13:12:38 UTC
Raising version to Rawhide to avoid bugzappers closing this bug.

Comment 31 Bug Zapper 2010-07-30 10:36:10 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:

Comment 32 Hedayat Vatankhah 2011-10-20 07:10:51 UTC
The bug is still there and really annoying. I don't want to have KDE packagekit handler to be started in Gnome when I click a package... :((

Comment 33 Yaakov Selkowitz 2013-01-14 06:07:38 UTC
WRT org.freedesktop.Notifications, most DEs provide their own service provider ("n-d") which is meant to best fit with the DE, e.g. (some of these may not be in Fedora):

* GNOME Shell (builtin)
* GNOME fallback (notification-daemon)
* KDE (builtin)
* MATE (mate-notification-daemon)
* Razor (qtnotifydaemon)
* Unity (notify-osd)
* XFCE (xfce4-notifyd)
* Awesome (builtin)
* E17 (builtin)

The only way to currently have multiple DEs installed and always get the "right" n-d for each desktop is for EVERY n-d to meet *all* the following criteria:

1) No n-d should provide a D-Bus service activation (.service) file.

GNOME already encountered this problem with GNOME Shell (builtin) vs. GNOME fallback (notification-daemon):


The same logic holds true for any others; if any standalone n-d provides a .service file, it is liable to cause a race condition with any other provider (standalone or builtin).

Those packages that currently provide a .service file should have those removed during %install.

2) Each DE SM must launch its n-d at login.

GNOME 3.x does this already via gnome-session.  The easiest way to accomplish this with the other standalone n-d's is to add a /etc/xdg/autostart/*.desktop file with the appropriate OnlyShowIn field, as listed here:


3) The n-d must remain running for the entire session.

Some n-d's exit after a certain idle time, relying on the D-Bus service activation to be restarted when needed again.  As that can't be relied upon in this case, the code must be patched to not do so.  Affected packages are notification-daemon (<= 0.7.0, patch mentioned above), mate-notification-daemon, and xfce4-notifyd, patches for which are available here:


The same logic and criteria should apply for any other D-Bus service for which multiple DEs ship their own provider.

Comment 34 Fedora Admin XMLRPC Client 2013-02-14 21:05:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 35 Fedora Admin XMLRPC Client 2013-02-22 15:07:07 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 36 Rex Dieter 2013-10-08 18:56:36 UTC
*** Bug 1016828 has been marked as a duplicate of this bug. ***

Comment 38 Rex Dieter 2017-10-09 11:44:54 UTC
*** Bug 1499743 has been marked as a duplicate of this bug. ***

Comment 39 Robert Moskowitz 2018-09-18 13:03:33 UTC
Problem is getting a dialog stating:

Error - XFCE PolicyKit Agent

when I connect via VNC to my Xfce system.

Things seem to work, but how would I know?


System is running Fedora-Xfce-armhfp-29_Beta-1.2-sda

Note I have not tried vnc to Xfce for any prior version of Fedora.

Connecting locally, I have no problem.  No PolicyKit error

I install tiger-vncserver, and change target to multi-user.

I do a bunch of steps to get Xfce working with vncserver.  I change the user/.vnc/xstart to end with:

# exec /etc/X11/xinit/xinitrc
exec  /bin/sh /etc/xdg/xfce4/xinitrc
xrdb $HOME/.Xresources
startxfce4 &

Note that currently, the is no .Xresources file.

When I connect to the user over vnc, I get my Xfce session with the XFCE - PolicyKit Agent error.  This happens everytime I restart the vncserver service (or reboot the system).

It MAY be that I do not have the right invocation magic for Xfce over vnc.  I have not been able to find any good information on this.  I suspect at least I need to add a GEOMETRY statement.

So either this is an Xfce invocation error or somewhere else in the system.  Thus I have posted this problem to this old bug which came up in my PolicyKit Agent search.

Comment 40 Greg Trounson 2019-11-11 00:06:27 UTC
This issue affects notifications in XFCE and, in turn, volume control and unmounting USB drives.

Both the plasma-workspace and xfce4-notifyd packages put D-Bus files in /usr/share/dbus-1/services:


and both claim the name "org.freedesktop.Notifications"

If a system has both KDE Plasma and XFCE desktop environments installed then the XFCE notification service does not start automatically.  Anything that would normally trigger a notification within XFCE instead freezes for about a minute.  Examples include:

- Issuing a notification command, eg: notify-send hello
- Adjusting the volume with the mouse wheel hovering over the Pulseaudio Plugin icon
- Attempting to un-mount or eject a drive in Thunar

Manually starting /usr/lib64/xfce4/notifyd/xfce4-notifyd fixes this immediately but is not persistent across reboots.

The journal reveals which D-Bus service is being ignored:

dbus-broker-launch[1786]: Service file '/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'
dbus-broker-launch[1786]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service'

Editing two lines in /usr/share/dbus-1/services/org.kde.plasma.Notifications.service and rebooting removes the naming conflict and allows notifications to appear correctly in both KDE Plasma and XFCE:

[D-BUS Service]
Exec=/usr/bin/plasma_waitforname org.freedesktop.PlasmaNotifications

Deleting this file entirely also has the same effect, so I'm not sure if this file is needed for anything at all now, since Plasma handles notifications in its own way.

Note You need to log in before you can comment on or make changes to this bug.