Tag Info

New answers tagged

1

As is often the case in matters such as these, the ArchWiki is your go-to about detailed information: here (addage: those with the best documentation shall eventually carry the day) Two, no three, items about network managers, the first being the only important one: Make sure only one is installed/active. If more than one is active your system will seem ...


1

As per the official docs (under standard interfaces): There are some standard interfaces that may be useful across various D-Bus applications. org.freedesktop.DBus.Introspectable This interface has one method: org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data) Objects instances may implement Introspect which returns ...


1

I am not sure you can do this programmatically in Python. You might but it will be a huge headache to figure out how. I tried to do it before and ended up hating Dbus. Anyhow I recommend to use d-feet if you want to investigate things. Below is a screenshot that I stole from my blog. Once you know the program name, object path, etc. you can then use ...


0

More searching suggested that logging out and back in to create a new desktop session would resolve the problem. I tried it and it worked. Apparently, even though gconfd-2 was running, it wasn't hooked up to D-BUS properly.


2

D-Bus isn't using the magic cookie file here; it's passing credentials over the UNIX domain socket (SCM_CREDENTIALS). The magic cookie file is only one of several D-Bus authentication mechanisms. D-Bus implements a SASL-compliant interface (see RFC4422) to support a wide range of authentication mechanisms. One of these mechanisms is called "EXTERNAL" ...


1

dconf-service is automatically started by the session daemon1 when needed, as per the same documentation page: Users or administrators should never need to start the service, as it will be automatically started by dbus-daemon(1) whenever an application tries to write settings. Reading values from the dconf database does not involve the service; it is only ...


0

Technically there isn't a reliable/official way to know whether a socket address corresponds to a DBUS session bus or not because the naming scheme for DBUS session bus addresses is private to the implementation: you're only supposed to launch dbus-daemon and opaquely use the address it chooses for itself. However, I can observe on my system that dbus-daemon ...


1

I think you can do in this way: in /etc/libvirt/libvirtd.conf unix_sock_group = "libvirt" unix_sock_rw_perms = "0770" auth_unix_rw = "none" After that restart the libvirtd daemon



Top 50 recent answers are included