DBus is broken on Xfce

[abbradar]

Issue description

When starting Xfce after an update, I get this:

$ echo $DBUS_SESSION_BUS_ADDRESS 
unix:abstract=/tmp/dbus-yvEWqzlS5z,guid=ce9642d21b094b432feae6cf5809f6bb;unix:abstract=/tmp/dbus-SZQEK1FwoS,guid=2276c0f34b70c1db887a93125809f6bb
$ ls /tmp/dbus-yvEWqzlS5z
ls: cannot access '/tmp/dbus-yvEWqzlS5z': No such file or directory

All applications that require DBus fail to start (e.g. taffybar).

Steps to reproduce

1. Start Xfce session;
2. Run anything dbus-dependent;
3. Observe an error.

   Technical details

   • System: (NixOS: nixos-version, Ubuntu/Fedora: lsb_release -a, ...) 09e4b78b48fa9b5da00f44d2c01f0f9f16c3d406 (with unrelated patches on top)

[abbradar]

Funny things happen when I try to use dbus-launch by myself.

Let's create a new DBus session daemon:

$ dbus-launch
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-GGeRMqFbPf,guid=d0021bc574263ed05cffbe485809fafd;unix:abstract=/tmp/dbus-cyeuTtqrgQ,guid=9c245041979c97f9d9e9e17b5809fafd
DBUS_SESSION_BUS_PID=9425

Okay, is the daemon running?

$ ps -A | grep 9425
 9425 ?        00:00:00 dbus-daemon

Good, does it listen for something?

$ lsof -p 9425
COMMAND    PID   USER   FD      TYPE             DEVICE SIZE/OFF      NODE NAME
...
dbus-daem 9425 abbradar    4u     unix 0x0000000000000000      0t0     61584 @/tmp/dbus-cyeuTtqrgQ type=STREAM
dbus-daem 9425 abbradar    5r  a_inode               0,11        0      7359 inotify
dbus-daem 9425 abbradar    6u     unix 0x0000000000000000      0t0     61585 @/tmp/dbus-GGeRMqFbPf type=STREAM
dbus-daem 9425 abbradar    7u     unix 0x0000000000000000      0t0     55916 type=STREAM
dbus-daem 9425 abbradar    8u     unix 0x0000000000000000      0t0     55917 type=STREAM

Oh, nice, it actually does listen on the socket that it advertised. Let's check this out!

$ ls /tmp/dbus-GGeRMqFbPf
ls: cannot access '/tmp/dbus-GGeRMqFbPf': No such file or directory

...now what? But wait, there's more! There is another socket, at least it should be!...

$ ls /tmp/dbus-cyeuTtqrgQ
ls: cannot access '/tmp/dbus-cyeuTtqrgQ': No such file or directory

...uh-oh. At this point my faith in everything is shattered.

I did a rollback for now. Any ideas what might this be? I'm not sure what to try next.

[grahamc]

O.o interesting. I suspected the upgrade (https://github.com/NixOS/nixpkgs/pull/19682) but you don't have it yet.

[abbradar]

Well, I did jump from a (pretty old) previous channel -- adfcc2d9531e78bf6a9e3b56e2f4fc873cb3d87b, so there might be many things involved. Maybe I'll do a bisect if I come up with a clever automated test for this.

EDIT: I read your message incorrectly, I assumed that you mean "commit with the bug is much later than the security update" (and in meantime other dbus-related things were touched). Doesn't make bisect a bad idea though, but first I'll try on current master.

[dezgeg]

Note that AFAIK @/tmp/dbus-cyeuTtqrgQ and /tmp/dbus-cyeuTtqrgQ are different - the @ one works in an abstract namespace, it doesn't exist in the file system.

(Probably this trivia doesn't help solving the problem though ;))

[abbradar]

Actually it does help -- I didn't know what @ signifies. Also it probably means that it's dbus that is doing something shady -- it's not like something forces it to create an abstract namespace I presume.

[abbradar]

From http://unix.stackexchange.com/questions/206386/what-does-an-symbol-denotes-in-the-beginning-of-a-unix-domain-socket-path-in-l it seems that it's known DBus behaviour, and indeed, I observe the same thing on my current generation (which works). So my analysis above is incorrect.

[abbradar]

Hm, perhaps I was wrong in assessing this -- can someone suggest a good DBus test, and also DBus-dependent applications? I feel that only taffybar doesn't work.

[rvl]

It's just taffybar (haskell-dbus) which can't handle semicolons in DBUS_SESSION_BUS_ADDRESS. I posted a possible workaround to the mailing list.

[abbradar]

Yes, it seems my cause seeking was inadequate. Thank you for the pointer!