i need a GNOME expert to help me with this. i'm running sway.

· · Web · 2 · 7 · 4

manually running /usr/libexec/gcr-prompter in another shell seems to work, but: how is a "D-BUS Service" normally run?

Show thread

monitoring with dbus-monitor --session yields: string "Could not get owner of name 'org.gnome.keyring.SystemPrompter': no such name"

Show thread

ok the fix is: dbus-update-activation-environment --systemd DISPLAY

now someone explain to me WHY

Show thread

@mntmn have you tried looking around the bus using d-feet?

@mntmn so what happened here is, it's a bust-activated service that wasn't running (name in italics IIRC), and when you tried to touch it (ask it for available methods/interfaces), dbus-daemon tried to spawn it, and then it exitted before responding to your request.

@wolf480pl ok thanks. apparently the dbus stuff doesn't know the DISPLAY variable or something? because "dbus-update-activation-environment --systemd DISPLAY" makes it work, i would like to understand why

just run `ps auxf` and see where dbus-daemon is, and where sway is, and how it couldn't possibly inherit DISPLAY

@mntmn when systemd was introduced, the session bus became user bus - there's only one no matter how many times you log in.
So the dbus-daemon is startede by systemd user instance, which doesn't have DISPLAY variable.
So all dbus-started thigns don't have DISPLAY variable, because that's specific to your session, and the user bus and systemd --user are supposed to be session-independent.

@wolf480pl ok, this makes sense! so it is because the dbus user session exists before i launch sway. because i login on the console.

@mntmn kinda, but then, even if you did have display manager, you could still do:

- login on display manager, user bus is started
- login on tty2 or ssh or anything else
- log out on display manager, user bus survives and becomes orphaned because you're still logged in on tty2,
- log in on display manager again
- now all dbus services have stale DISPLAY

I mean, it can happen that Xwayland will reuse the same display number but you shouldn't count on that

I think a better way to do it is to do the dbus-update-activation-environment whenever you start a new DISPLAY. Also, if some process allows you to update DISPLAY of a running instance of it (eg. gpg-agent allows this), do that as well.
This will mean the pop-ups will only display on the last started session, but it's as good as it gets.

There's no way to do it right without reintroducing session bus, which breaks systemd, unless you have user bus as well, and somehow overlayfs them

@wolf480pl ok, wow you seem to have a wealth of experience with this!

@mntmn I mean, I assume it will break systemd --user, because parts of systemd use it internally.

I haven't tested it. I don't have experience with it. I mostly just read some stuff on the internet, some manpages, looked around process trees and services on the bus.

I do have some experience with gpg-agent and pinentry on sway, had a similar issue with DISPLAY. But the rest of the stuff is just inference from residual observation.

@mntmn 5 years ago I tried to write a union-filesystem-like proxy for dbus with the intent to reintroduce session bus, but never got far with it.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!