Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nixos/display-managers: Use dbus socket unit shipped by upstream #88101

Merged
merged 1 commit into from May 19, 2020

Conversation

adisbladis
Copy link
Member

@adisbladis adisbladis commented May 18, 2020

This ensures a correct DBUS_SESSION_BUS_ADDRESS environment variable
is set and imported into the systemd user environment.

Previously this would refer to a non-existing path preventing commands
interacting with the systemd manager from working.

Closes #87502

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

This ensures a correct DBUS_SESSION_BUS_ADDRESS environment variable
is set and imported into the systemd user environment.

Previously this would refer to a non-existing path preventing commands
interacting with the systemd manager from working.

Closes NixOS#87502
Copy link
Contributor

@hedning hedning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me 👍

@adisbladis adisbladis requested a review from flokli May 18, 2020 23:53
@adisbladis
Copy link
Member Author

This seems to have broken the Gnome3 test and I don't understand why.
Could someone from @NixOS/gnome take a look?

@hedning
Copy link
Contributor

hedning commented May 19, 2020

Hmm, that seems pretty weird as gnome doesn't launch through that code path (it just uses the upstream session files).

The last trunk-combined eval reports a gnome test failure: https://hydra.nixos.org/build/119237820. I didn't investigate it further, but it could be an unrelated issue.

@adisbladis
Copy link
Member Author

adisbladis commented May 19, 2020

Hmm, that seems pretty weird as gnome doesn't launch through that code path (it just uses the upstream session files).

I thought it was weird too.. Actually this error on Hydra is exactly what I was seeing too.
It turns out it's just test flakiness and the tests are passing just fine after a few attempts.

@adisbladis adisbladis closed this May 19, 2020
@adisbladis adisbladis reopened this May 19, 2020
@adisbladis
Copy link
Member Author

@GrahamcOfBorg test plasma5 i3wm gnome3 systemd

@adisbladis
Copy link
Member Author

Since this doesn't seem to break anything and fixes a super annoying and hard to track down problem I'm just gonna go ahead and merge.

@adisbladis adisbladis merged commit 740f4ba into NixOS:master May 19, 2020
@DamienCassou
Copy link
Contributor

Thank you so much @adisbladis

@eadwu
Copy link
Member

eadwu commented May 20, 2020

It doesn't set $DBUS_SESSION_BUS_ADDRESS, which ends up breaking gnome3 pinentry for me.

Manually running systemctl --user restart [dbus.service|dbus.socket] makes pinentry work when signing with gpg but calling the executable directly seems to be broken still (if it wasn't suppose to).

@adisbladis
Copy link
Member Author

@eadwu It does set it in the ExecStartPost section of the unit:
ExecStartPost=-/nix/store/fwaclgpjqbrz2dwq3alm49swzzrvv4p7-systemd-245.5/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus

@eadwu
Copy link
Member

eadwu commented May 20, 2020

My service looks fine but I don't have the env set

❯  systemctl --user cat dbus.socket
# /nix/store/h81xpkmcs4b5d1cmkgwwjkmzdd6x9zar-dbus-1.12.16/etc/systemd/user/dbus.socket
[Unit]
Description=D-Bus User Message Bus Socket

[Socket]
ListenStream=%t/bus
ExecStartPost=-/nix/store/fwaclgpjqbrz2dwq3alm49swzzrvv4p7-systemd-245.5/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=%t/bus

# /nix/store/pbjz177csqxyi01g94sj7r50pfchr5fp-user-units/dbus.socket.d/overrides.conf
[Unit]

[Socket]


❯  systemctl --user status dbus.socket
● dbus.socket - D-Bus User Message Bus Socket
     Loaded: loaded (/nix/store/h81xpkmcs4b5d1cmkgwwjkmzdd6x9zar-dbus-1.12.16/etc/systemd/user/dbus.socket; indirect; vendor preset: enabled)
    Drop-In: /nix/store/pbjz177csqxyi01g94sj7r50pfchr5fp-user-units/dbus.socket.d
             └─overrides.conf
     Active: active (running) since Wed 2020-05-20 13:30:14 EDT; 4min 23s ago
   Triggers: ● dbus.service
     Listen: /run/user/1000/bus (Stream)
    Process: 7806 ExecStartPost=/nix/store/fwaclgpjqbrz2dwq3alm49swzzrvv4p7-systemd-245.5/bin/systemctl --user set-environment DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus (code=exited, status=0/SUCCESS)
     CGroup: /user.slice/user-1000.slice/user@1000.service/dbus.socket
❯  echo $DBUS_SESSION_BUS_ADDRESS

@rycee
Copy link
Member

rycee commented May 20, 2020

The DBUS_SESSION_BUS_ADDRESS would only be set inside the systemd user session. I imagine the variable would not be available to the user environment as a whole.

I'm curious, though, why you aren't getting the "Unit xyz.service not found" error for dbus activated services. For example Gnome Terminal. Search for "Error constructing proxy" in #17943 (comment) to see what I mean. Is you gnome-terminal package installed in the system or user profile?

@eadwu
Copy link
Member

eadwu commented May 20, 2020

I don't have gnome-terminal installed, afaik the only use case I'm getting an error related to this so far is when signing with gpg where it needs to ask for passphrase.

Here's some output when signing a commit

May 20 14:38:00 gpg-agent[24583]: command 'PKSIGN' failed: Inappropriate ioctl for device <Pinentry>
May 20 14:38:00 gpg-agent[24583]: failed to read the secret key
May 20 14:38:00 gpg-agent[24583]: failed to unprotect the secret key: Inappropriate ioctl for device
May 20 14:38:00 gpg-agent[2948]: Failed to lookup password for key n/{{fingerprint}} with secret service: Unknown or unsupported transport “disabled” for address “disabled:”
May 20 14:38:00 gpg-agent[2948]: No Gcr System Prompter available, falling back to curses

Running pinentry directly

❯ /nix/store/wy6ixcj6zc08lahq8lk2g0in2pk9ds1g-pinentry-1.1.0-gnome3/bin/pinentry
No $DBUS_SESSION_BUS_ADDRESS found, falling back to curses
OK Pleased to meet you
^C

If I revert this commit, $DBUS_SESSION_BUS_ADDRESS is available to the whole user environment for me.

@adisbladis
Copy link
Member Author

@eadwu Could you try to apply adisbladis@18a0db3 and see if this fixes it for you?

@adisbladis
Copy link
Member Author

adisbladis commented May 20, 2020

@eadwu I've left services.dbus.socketActivated as the default false and confirmed in the repl that it's still false.

@eadwu
Copy link
Member

eadwu commented May 20, 2020

Yeah I figured out I kept the reverted commit in my nixpkgs after posting it.

@eadwu
Copy link
Member

eadwu commented May 20, 2020

@adisbladis That patch exports $DBUS_SESSION_BUS_ADDRESS for me and fixes the problem.

On other details, it seems this might(?) because of how a specific way an applications asks for gpg-agent or pinentry (not sure how it works). Without the patch and without $DBUS_SESSION_BUS_ADDRESS in the user env, Thunderbird is able to decrypt emails but VSCode is unable to sign commits. With the patch, signing commits through VSCode works.

@adisbladis
Copy link
Member Author

Alright, pushed fixup in 0f1eb8c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wrongly configured org.freedesktop.systemd1 service on user's dbus session with i3
5 participants