On Fri, 15 Feb 2013 08:13:32 +0100, Bastien Nocera wrote:
Could you tell me a test environment where auto-starting the daemon is
reproducible? Then I might take a look at trying to avoid it.
It should be auto-started when your app pokes at the not-yet-spawned
well-known D-Bus name.
There's an error upon trying to talk to it:
The name org.gnome.SettingsDaemon was not provided by any .service files
It seems something wants to start it but couldn't without the .service
file.
I've also tried Fedora 17 where g-s-d is not auto-started either.
I've also tried Fedora 18 _without_ GDM but with startx and fvwm.
Always the same error message.
As pointed out above, with Openbox the daemon is not started automatically
when starting Audacious. I'm stuck there. The puzzle is incomplete.
Is there a session D-Bus running in your session? I don't know how it
could not start.
At the bottom of the message you replied to:
http://lists.fedoraproject.org/pipermail/devel/2013-February/178617.html
$ ps ax|grep dbus
646 ?Ssl0:01 /bin/dbus-daemon --system --address=systemd:
--nofork --nopidfile --systemd-activation
20236 ?S 0:00 dbus-launch --sh-syntax --exit-with-session
20237 ?Ssl0:00 /bin/dbus-daemon --fork --print-pid 4
--print-address 6 --session
20443 ?Sl 0:00 /bin/dbus-daemon
--config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
20900 pts/0S+ 0:00 grep --color=auto dbus
You should use dbus_g_proxy_new_for_name_owner() instead, which will
round-trip and check whether the service exists.
Then my (preliminary) solution from yesterday can't be too bad, since
if there's no owner the plugin refuses to talk to dbus.
Hopefully it should stop it from auto-spawning.
You said hopefully. ;-) Yeah, a test environment would be good.
--
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git2.1.fc19.x86_64
loadavg: 0.15 0.10 0.07
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
