McdDispatcher could call o.f.DBus.ReloadConfig() (or whatever it's really called) just before calling ListActivatableNames()? 11:28 < grundleborg> should MC rescan for .client files whenever it is launched? I'm having weird problems getting it to register all the auto-activatable clients on my system 11:30 < smcv> grundleborg: .client file does not imply activatable 11:30 < smcv> grundleborg: .service implies activatable 11:30 < smcv> grundleborg: dbus-daemon is meant to inotify for them, but it doesn't always work, afaics 11:32 < smcv> grundleborg: MC just asks the dbus-daemon what's activatable, so if the dbus-daemon hasn't noticed, you lose 11:32 < smcv> grundleborg: arguably MC should force dbus-daemon to reload just before doing that? patches welcome This doesn't solve the "activatable client added during runtime" use-case, for which we need to make dbus-daemon's inotification actually work.
Reported this bug upstream to dbus: bug #23925
Since 5.3.0, we work around this in the way I suggested.
... which turns out to cause dbus-daemon to forget its internal state and drop pending service-activations on the floor, so we'll have to revert this.
(In reply to comment #3) > ... which turns out to cause dbus-daemon to forget its internal state and drop > pending service-activations on the floor, so we'll have to revert this. That was fixed in dbus 1.2.18, which is now the old-stable branch of D-Bus (i.e. no security support for anything older), so we could probably safely reinstate this.
(In reply to comment #1) > Reported this bug upstream to dbus: bug #23925 ... which is fixed in 1.2.x, and the current stable is 1.6. Yay! *** This bug has been marked as a duplicate of bug 23925 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.