As I recall, a weird issue where method calls were timing out for no apparent reason turned out to have this cause: • App 1 calls a method M1 on GConf; the daemon starts service-activating GConf; • App 2 calls a method on Mission Control, which as an implementation detail calls ReloadConfig() on the daemon (to pick up newly-installed .service files so they appear in ListActivatableNames()); • The daemon restarts itself and throws away most of its state, *forgetting M1 in the process*; • GConf finishes starting, but the daemon has thrown away its context so doesn't deliver M1 to it; • M1 times out, App 1 fails, everyone dies. (Sjoerd, correct me if the above is wrong?) So obviously MC no longer calls ReloadConfig(). :-) If the daemon properly inotified on the service file dirs, or indeed just rescanned them on each call to ListActivatableNames (as it does when it actually wants to activate things) then that would avoid the issue that MC was working around. But it shouldn't be possible to make the daemon lose messages...
24350 has possible patch *** This bug has been marked as a duplicate of bug 24350 ***
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.