Nixpkgs: dbus-update-activation-environment is broken

[ttuegel]

Issue description

$ dbus-update-activation-environment --systemd --all
dbus-update-activation-environment: warning: error sending to systemd:
org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1
exited with status 1

I believe this is due to systemd --user not running on the session bus. This is in turn caused (I think) by the fact that NixOS is not using socket activation for D-Bus.

Steps to reproduce

1. Log in to a KDE 5 session.
2. Enter the command above in any terminal.
   

   Technical details

• System: 16.09.git.fb0f394 (Flounder)
• Nix version: nix-env (Nix) 1.12pre4523_3b81b26
• Nixpkgs version: 1df4dd6bf568a5eb75f07a60bda4e5ca406cc7b4

/cc systemd maintainer @edolstra

[ttuegel]

I am rebuilding dbus with --enable-user-session to see if this resolves the problem.

[ttuegel]

I am rebuilding dbus with --enable-user-session to see if this resolves the problem.

This doesn't help, and also breaks X logins.

[peterhoeg]

Try with this commit: https://github.com/peterhoeg/nixpkgs/commit/83cb6ec399e067b0d111abc39381204d1796758f

I have been running with that patch applied locally for months.

[ttuegel]

Thanks, I'll try that.

The problem with --enable-user-sessions may have been a failure to set up the environment correctly. I'll investigate that, too. In the long run, we'll need socket activation through systemd as that will be the only way to get a session bus with kdbus. That's not an immediate concern, though.

[ttuegel]

@peterhoeg Your patch seems to work. I'll see about integrating it into master.

[peterhoeg]

There was an issue earlier with this change breaking xfce (both one of the tests and the actual thing), but at some point things started working with xfce. There might be other breakage out there, but I only use KDE.

[vandenoever]

I'm still seeing this issue on NixOS 16.09 and it prevents me from running KDE. How can I apply @peterhoeg 's patch on that system level?

[peterhoeg]

@vandenoever, the patch is upstream, but deactivated by default. Try this:

services.dbus.socketActivated = true;

dbus doesn't like being restarted due to the processes it spawns being killed without a way to restart them, so I will suggest you try rebooting afterwards. That situation will improve once more user services are converted for spawning by systemd.

[rycee]

Today I've been digging a bit into the user session dbus in NixOS. I think it is pretty broken at the moment, in particular w.r.t activating systemd services and interacting with systemd. Warning, wall of text incoming!

For example, I'd like to use the --wait option but systemctl --user --wait start xyz.service will error out with

Process org.freedesktop.systemd1 exited with status 1

just like dbus-update-activation-environment --systemd --all does. Further when Dunst (my notification daemon) gets dbus activated I get a dunst process but it is not run through the corresponding service file:

$ systemctl --user is-active dunst.service
inactive
$ ps ax | grep dunst
13823 ?        Sl     0:00 /nix/store/dsjzddn5q3bxliws90mc70kgcz6rdwnx-dunst-1.2.0/bin/dunst
$

We can try changing /etc/dbus-1/session.conf to have <listen>unix:runtime=yes</listen> instead of <listen>unix:tmpdir=/tmp</listen>. Then dbus will create a socket at $XDG_RUNTIME_DIR/bus, just like systemd expects. But, alas, since dbus by default is started with the X session using dbus-launch it is too late for systemd to get in. Fortunately we can reexec the user systemd to recover the functionality:

$ systemctl --user --wait start random-background.service
Failed to enable subscription: Process org.freedesktop.systemd1 exited with status 1
$ dbus-update-activation-environment --systemd --all
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.Spawn.ChildExited: Process org.freedesktop.systemd1 exited with status 1
$ nix-shell -p qt5.qttools.bin --run qdbus | grep systemd1
$ systemctl --user daemon-reexec
$ nix-shell -p qt5.qttools.bin --run qdbus | grep systemd1
 org.freedesktop.systemd1
$ systemctl --user --wait start random-background.service
$ dbus-update-activation-environment --systemd --all
$

Not very convenient but it works, sort of. The issue of service activation still remains and we still get the same result with Dunst. Basically, the issue here seems to be that dbus-launch doesn't start dbus-daemon with the --systemd-activation option. The only reasonable solution to this seems to be moving to a socket activated dbus service.

So I add services.dbus.socketActivated = true; to my system configuration. Now, things are fine and dandy:

$ systemctl --user --wait start random-background.service
$ dbus-update-activation-environment --systemd --all
$ ps ax | grep dunst
18349 ?        Ssl    0:00 /nix/store/dsjzddn5q3bxliws90mc70kgcz6rdwnxdunst-1.2.0/bin/dunst
$ systemctl --user is-active dunst.service
active
$ gnome-terminal
Error creating terminal: The name org.gnome.Terminal was not provided by any .service files
$ # Damn!

So, dbus can't find the dbus service file since it is in ~/.nix-profile/share/dbus-1/services and for whatever reason it wasn't enough to do dbus-update-activation-environment for it to honor XDG_DATA_DIRS. I don't know if this is expected or not. In any case lets set this variable earlier in the login process by putting XDG_DATA_DIRS DEFAULT=@{HOME}/.nix-profile/share in ~/.pam_environment (putting it in environment.sessionVariables didn't work because the opengl module insisted on having sole access to XDG_DATA_DIRS):

$ gnome-terminal
Error constructing proxy for org.gnome.Terminal:/org/gnome/Terminal/Factory0: Error calling StartServiceByName for org.gnome.Terminal: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit gnome-terminal-server.service not found
$ # Double damn!

So, as it turns out, the service providing org.gnome.Terminal gets installed to ~/.nix-profile/lib/systemd/user and systemd hasn't been told to look for services there! Since systemd honors XDG_DATA_DIRS we'll update ~/.pam_environment to

XDG_DATA_DIRS DEFAULT=@{HOME}/.nix-profile/share:@{HOME}/.nix-profile/lib

and logging out and back in (for the nth time) gives us

$ gnome-terminal
$ ps ax | grep gnome-terminal-server
21263 ?        Ssl    0:00 /nix/store/cjzl5z8c372l2iarx04vw1d4cg9jmvxm-gnome-terminal-3.24.2/libexec/gnome-terminal-server
$ systemctl --user is-active gnome-terminal-server.service active
active
$ # Success!

From what I can tell everything now works :-)

My conclusions from this little adventure is that the current default dbus setup causes pretty severe loss in functionality. To fix this NixOS should move to dbus socket activation by default (or even completely remove non-socket activated session dbus).

But, as illustrated above, it is not enough to just change the default value of the services.dbus.socketActivated option, we should also make sure that the XDG variables are set by PAM, not just in /etc/profile. Unfortunately, having ~/.nix-profile/lib in XDG_DATA_DIRS seems a bit too general. I'm not sure what would be the best way to avoid it, perhaps patching systemd or setting up a symlink ~/.nix-profile/share/systemd that points to ~/.nix-profile/lib/systemd?

[benley]

My conclusions from this little adventure is that the current default dbus setup causes pretty severe loss in functionality. To fix this NixOS should move to dbus socket activation by default (or even completely remove non-socket activated session dbus).

What are the remaining obstacles to making dbus socket activation the default?

[peterhoeg]

None really - we've been running with that setup for the last year on both workstations and servers without any problems. Do keep in mind though that there are no user installed packages - it's all in the global environment.

[rycee]

Yeah, I think it should work pretty well for globally installed packages but for user installed packages I think the situation is still as I outlined above. Unfortunately I haven't had time to work on it.

Since I install packages mostly in my user profile I would prefer not to switch to socket activation by default until the issues are fixed.

[coretemp]

I have gnome3.gnome_terminal in my system configuration as well as services.dbus.socketActivated = true;, logged in again, but gnome-terminal doesn't start (with the message as described above).

[rycee]

@coretemp You could try adding services.dbus.packages = [ pkgs.gnome3.gnome_terminal ]; to your configuration. That may fix the issue but systemd may still miss the service file…

[coretemp]

services.gnome3.gnome-terminal-server.enable = true; services.dbus.packages = [ pkgs.gnome3.gnome_terminal ];services.dbus.socketActivated = true; works on NixOS.

[rycee]

Ah, looking at the gnome-terminal-server module it seems to do everything necessary, including services.dbus.packages = [ pkgs.gnome3.gnome_terminal ]; so you shouldn't need that setting.

[bignaux]

I would notice that the problem is same when you remove a package, the service file is removed from ~/.nix-profile/share/dbus-1/services but the service still remain activate. Notice that if the service is required by another package you install, org.gna.home.a2jmidid.service for the cadence example, it will not be installed in the ~/.nix-profile/share/dbus-1/services/ directory anyway, so we need mecanism to manage that well, nowaday, package depends more and more on service that statics files.

no more chance with
dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

[stale[bot]]

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.