GNOME Bugzilla – Bug 688313
Each DBus interface exporting plugin should claim its own name
Last modified: 2012-12-19 16:20:32 UTC
I've noticed this with the power plugin in particular: gnome-shell's
power indicator uses a GDBusProxy to watch dbus properties exported
from the power plugin. When restarting g-s-d, those properties are not
updated because the watch is done on g-s-d's name but when that shows
up the power plugin interface hasn't been exported yet.
It seems to me that we need to either do this or have a signal on the
plugins so that they can tell the main g-s-d code when they're
finished initializing and have exported their DBus interfaces and only
then claim the name.
Created attachment 228960 [details] [review]
power: Claim a well-known name on the bus
By relying on the main gnome-settings-daemon bus name we have a race
condition in that the name is claimed before the plugins are loaded
and so any interfaces exported from plugins are not readily available
when the name shows up on the bus.
I think your patch would work. However I think it would be better if gnome-settings-daemon just waited claiming its well-known name ("org.gnome.SettingsDaemon") until all plugins are laoaded.
(In reply to comment #2)
> However I think it would be better if
> gnome-settings-daemon just waited claiming its well-known name
> ("org.gnome.SettingsDaemon") until all plugins are laoaded.
This still wouldn't help the case of disabling and enabling plugins, I think.
g-s-d's plugins are conceptually orthogonal to each other so I still think that claiming their own names would work best for this specific case.
My recommendation here is the same as comment 2 - claim the name late, and use some other mechanism for process exclusion.
Review of attachment 228960 [details] [review]:
This should be 3 separate patches. Why is the power plugin the only one monitoring the name ownership? Does it break gnome-settings-daemon's --replace?
What about the XRandR plugin?
I would also need a complete list of the impacted modules (and plugins within those modules if necessary).
Committed in a couple of separate patches, thanks for noticing.