DBus and Xfce

[abbradar]

Issue description

DBus currently seems broken on Xfce -- for example, services.gnome-keyring doesn't work for me. Reverting 29667f6. fixes it; that suggests problem is that dbus-daemon is started not by systemd but by Xfce itself, so it misses arguments and expects its configuration in /etc/dbus-1. systemctl --user status dbus shows that the service is not started on Xfce, which confirms this theory.

EDIT: Additionally, services.dbus.socketActivated fixes SSH agent but then Chromium and some other applications begin to take forever to start up; strace shows that they get a DBus-related error from some fd.

Steps to reproduce

1. Start Xfce;
2. Attempt to use GNOME keyring (e.g. SSH agent).

Technical details

• Nixpkgs version: (run nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion) f66d782

[cstrahan]

For the sake of linking the two issues/PRs: #20871

[layus]

Hi @abbradar,
Could you find what command is used by xfce to start the session dbus instance ? How was it able to pick /etc/dbus-1 when it should look for /usr/share/dbus-1 ?

[abbradar]

A grep in xfce.xfce4session shows that it uses dbus-launch, without any parameters.

EDIT: actually with some but unrelated: --sh-syntax, --exit-with-session.

[abbradar]

After some more digging it seems that when configuration is stored in /etc/dbus-1 dbus needs just --system or --session argument to work. See abbradar@6875797 -- with this my desktop runs correctly.

[layus]

:-) Or, you could just drop the ExecStart part, because --system and --session are what dbus does by default.

[layus]

See systemctl cat dbus and systemctl --user cat dbus

[abbradar]

Yep, it works! See #22343; it'd be nice if you could review.

[layus]

My feeling in this issue is that while putting files in /etc might seemingly solve the issue, the files in /etc may not be read at all. See

nixpkgs/nixos/modules/services/system/dbus.nix

Line 147 in 29667f6

environment.pathsToLink = [ "/etc/dbus-1" "/share/dbus-1" ];

and

nixpkgs/pkgs/development/libraries/dbus/default.nix

Line 53 in ea42d6f

"--datadir=/run/current-system/sw/share"

.
To me, this hints that it may work for some reason we do not understand. An not do what we think it does.
For example, the services uses both

nixpkgs/nixos/modules/services/system/dbus.nix

Line 147 in 29667f6

environment.pathsToLink = [ "/etc/dbus-1" "/share/dbus-1" ];

and

nixpkgs/nixos/modules/services/system/dbus.nix

Lines 67 to 80 in 29667f6

	packages = mkOption {
	type = types.listOf types.path;
	default = [ ];
	description = ''
	Packages whose D-Bus configuration files should be included in
	the configuration of the D-Bus system-wide or session-wide
	message bus. Specifically, files in the following directories
	will be included into their respective DBus configuration paths:
	<filename><replaceable>pkg</replaceable>/etc/dbus-1/system.d</filename>
	<filename><replaceable>pkg</replaceable>/share/dbus-1/system-services</filename>
	<filename><replaceable>pkg</replaceable>/etc/dbus-1/session.d</filename>
	<filename><replaceable>pkg</replaceable>/share/dbus-1/services</filename>
	'';
	};

Why use both ? and how do they interact ?

[layus]

@abbradar For example, if you strace -ff -e trace=file dbus-launch, you will see that dbus does not look at /etc. Do you also observe that behavior ?

[abbradar]

I can't reproduce this, for me strace shows:

[pid 12068] open("/run/current-system/sw/share/dbus-1/session.conf", O_RDONLY) = 4
[pid 12068] open("/etc/dbus-1/session.conf", O_RDONLY) = 4

[abbradar]

Oh, I found it:

  <!-- Include legacy configuration location -->
  <include ignore_missing="yes">/etc/dbus-1/session.conf</include>

in ${dbus}/share/dbus-1/session.conf.

[layus]

Ok, so you see that dbus loads /run/current-system/sw/share/dbus-1/session.conf. That file comes from upstream and is only kept to allow the dbus module to modify it (see

nixpkgs/nixos/modules/services/system/dbus.nix

Lines 25 to 45 in f66d782

	configDir = pkgs.runCommand "dbus-conf"
	{ preferLocalBuild = true;
	allowSubstitutes = false;
	}
	''
	mkdir -p $out
	cp ${pkgs.dbus.out}/share/dbus-1/{system,session}.conf $out
	# include by full path
	sed -ri "s@/etc/dbus-1/(system|session)-@$out/\1-@" $out/{system,session}.conf
	sed '${./dbus-system-local.conf.in}' \
	-e 's,@servicehelper@,${config.security.wrapperDir}/dbus-daemon-launch-helper,g' \
	-e 's,@extra@,${systemExtraxml},' \
	> "$out/system-local.conf"
	sed '${./dbus-session-local.conf.in}' \
	-e 's,@extra@,${sessionExtraxml},' \
	> "$out/session-local.conf"
	'';

). Loading that files means that something is wrong. The file we setup for dbus to load is located in "/nix/store/...-dbus-conf/system.conf".
This needs to be addressed before making yet another change to dbus.

[abbradar]

I looked through it and it seems to me that we don't actually need to modify it -- we can just use the upstream version. The only modification is used to force D-Bus to use ${configDir} instead of /etc/dbus-1, but we link configDir exactly there so this is a non-issue. See 72b3746

[abbradar]

BTW I think this file is used because of this line.

[layus]

The current behavior is due to a commit (783c40e) from @vcunat that set the datadir of dbus to "/run/current-system/sw/share". (

nixpkgs/pkgs/development/libraries/dbus/default.nix

Line 53 in f66d782

"--datadir=/run/current-system/sw/share"

)

I wonder why such a NixOS specific path was used in the configuration of the package. I guess this is because there are not many users of our dbus package outside of NixOS. Such a setup makes dbus very special compared to other services.

[abbradar]

@vcunat Maybe we can remove this option? Then dbus will use its configuration from $out/share/dbus-1 and correctly include our -local files from /etc/dbus-1. Perhaps not a high priority -- as @layus mentioned there are probably no/very few people who run D-Bus daemon from nixpkgs on non-NixOS, but this also feels cleaner to me.

[vcunat]

:-) certainly don't feel bounded by that commit of mine. I don't remember it, but I'm fairly certain my understanding of dbus was minimal at that time (and it hasn't improved much since).