Nixpkgs: Weird DBUS_SESSION_BUS_ADDRESS breaks applications that use dbus

[srhb]

Describe the bug
DBUS_SESSION_BUS_ADDRESS is weird!

❯ systemctl --user show-environment -l | grep DBUS
DBUS_SESSION_BUS_ADDRESS=$'unix:abstract=/tmp/dbus-GA2IKiC52i,guid=bffe67fa0b24050935ab98585d78ef9c;unix:abstract=/tmp/dbus-kPD3JS7CAD,guid=f9857fcf07334966151d82cc5d78ef9c'

Since #67363 (ccd8421dc9da745c2d44013e8f9eccd78cdf5bdc specifically), when I log in with LightDM, my DBUS_SESSION_BUS_ADDRESS appears to have more than one address, which breaks at least taffybar (though I suppose this might be a broken application if this is an acceptable value for the var.)

I don't know that LightDM is the culprit and suspect not, but that's what I tested with.

To Reproduce

1. Log in with your DM (possibly specifically with LightDM)
2. systemctl --user show-environment -l | grep DBUS

Expected behavior
One address is in the var

Metadata

❯ nix run nixpkgs.nix-info -c nix-info -m
 - system: `"x86_64-linux"`
 - host os: `Linux 5.2.13, NixOS, 19.09.git.e19054a (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3`
 - channels(root): `""`
 - channels(sarah): `""`
 - nixpkgs: `/home/sarah/src/nixpkgs`

cc @worldofpeace

[srhb]

Just tested with sddm as well, looks like LightDM indeed has nothing to do with the problem, as suspected.

[srhb]

From the dbus-launch man page:

(The bus address variable contains a comma-separated list of addresses to try.)

But that seems surprising given the normal value, eg. something like unix:abstract=/tmp/dbus-$xxx,guid=$yyy

[worldofpeace]

@srhb We've been looking into the same problem 🤣️

In particular, for me at least, this was causing issues in elementary-greeter

• https://github.com/elementary/greeter/issues/318

in there at least I noticed that DBUS_SESSION_BUS_ADDRESS wasn't set in the greeter session.

Found a bug report tied to lightdm

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829557
  didn't look at it too extensively.

But that seems surprising given the normal value, eg. something like unix:abstract=/tmp/dbus-$xxx,guid=$yyy

In on my current machine and with systemd it's

unix:path=/run/user/1000/bus,guid=$some_numbers

Though reproducing my setup in a vm it's /tmp/dbus-*

And there's this going on in lightdm's home

[root@nixos:/var/lib/lightdm/.dbus/session-bus]# cat 181cd21ce7ce43dca4596091b8579442-0 
# This file allows processes on the machine with id 181cd21ce7ce43dca4596091b8579442 using 
# display :0 to find the D-Bus session bus with the below address.
# If the DBUS_SESSION_BUS_ADDRESS environment variable is set, it will
# be used rather than this file.
# See "man dbus-launch" for more details.
DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-zAZSr2eGyi,guid=3871314941a833927bffde935d78f8f8'
DBUS_SESSION_BUS_PID=843
DBUS_SESSION_BUS_WINDOWID=6291457

So I'm guessing that file is used because it isn't set?

[samdoshi]

I think the Haskell dbus package is also affected by this. That may explain why taffybar is broken.

Interestingly there was a patch to fix it included in nixpkgs: https://github.com/NixOS/nixpkgs/commit/dd8f60fbd94c09ae6bbc4553079cd199a1635dfc

But has since been removed: https://github.com/NixOS/nixpkgs/commit/87ec7bb087b7d475c9118dcfff8b35ef62f8ce1a

[cumber]

It's probably valid to have multiple addresses?

According to the DBUS specification on server addresses:

Server addresses consist of a transport name followed by a colon, and then an optional, comma-separated list of keys and values in the form key=value. Each value is escaped.

When connecting to a server, multiple server addresses can be separated by a semi-colon. The library will then try to connect to the first address and if that fails, it'll try to connect to the next one specified, and so forth.

But it's not totally clear to me from the spec whether the environment variable DBUS_SESSION_BUS_ADDRESS should contain only a single address. It says:

The address of the login session message bus is given in the DBUS_SESSION_BUS_ADDRESS environment variable.

But nothing that I saw really clarifies whether a semi-colon-separated list is a kind of address, and so can be stored in DBUS_SESSION_BUS_ADDRESS, or whether they mean that an address is only singular so that's all that should be expected in DBUS_SESSION_BUS_ADDRESS but you can pass a list of addresses to the library (obtained from somewhere else?).

The haskell dbus package seems to take the latter interpretation; it contains separate internal functions for parsing a single address and for parsing a list of addresses, and uses the singular version in its connectSession function. I believe that's why taffybar is dying.

The patch @samdoshi linked looks like it gets past the problem by just taking the first address, which raises the question about what's changed that Nixos is now providing 2 of them (I confirmed by launching the old generation prior to taffybar breaking that we used to get only one). Is it actually correct for an application to only connect to the first address and ignore the second? If so, why do we even have the second address?

[srhb]

According to systemd's docs

This variable can contain multiple addresses separated by ;. If this variable is not set, a suitable default for the default user D-Bus instance will be used.

[IvanMalison]

@srhb This is now fixed in the newest taffybar 3.2.2 as it has been fixed in the haskell-dbus library.

taffybar is (for unrelated ghc 8.8 reasons) marked as broken in nixpkgs, but all of the build issues have been resolved and 3.2.2 should be unbroken and available soon.

[IvanMalison]

does this affect anything other than programs that use (now old) versions of the dbus library? If not then it can probably be closed.

[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.