On Mon, 12 Jan 2026 at 14:24:13 +0100, Samuel Thibault wrote: > Simon McVittie, le lun. 12 janv. 2026 12:33:50 +0000, a ecrit: > > Meanwhile, Samuel though that XDG_VTNR=2 should be copied from the > > graphical login session into the `systemd --user` service manager, > > dbus-daemon and similar processes so that orca would inherit it > > Yes. Provided that the process is related to the graphical session. > Which is the case of anything that is started by the session for the > graphical desktop, which is the case of Orca.
But that isn't an option that is available to us: neither `systemd --user` nor `dbus-daemon --session` have a way to distinguish between user-services that are related to the graphical session (e.g. orca, gnome-terminal), user-services that are not (e.g. dirmngr, xdg-permission-store) and user-services that could reasonably be argued either way (e.g. gvfs, pipewire). There's only one activation environment[1] so we can either have XDG_VTNR be inherited by every user-service, like DISPLAY, or by none of the user-services, like XDG_VTNR at the moment; those are the choices. There's currently no mechanism for it to be inherited by half of the user-services but not the other half, which is why we need to find a consensus on which of the two extremes is intended/correct and then stick to it. As a data point, when gnome-session copies environment variables from its startup environment to the activation environment, it specifically excludes NOTIFY_SOCKET, XDG_SEAT, XDG_SESSION_ID and XDG_VTNR[2], suggesting that the gnome-session developers are among those who believe those variables are only meant to be set inside the actual login session. > As a matter of fact, orca *is*. It's just that apparently the startup of > the graphical session (and thus orca) has moved from session-22.scope to > [[email protected]], thus bringing the mess. (You said user-1000.slice, but I assume you meant [email protected], which is the parent of all user-services: user-1000.slice is the common parent of [email protected] and all login sessions of uid 1000.) > > I had always assumed that XDG_VTNR=2 should be set for members of > > session-22.scope (often almost empty on a modern system) > > Being empty is the thing I see questionable there. That's a consequence of a design change in orca and/or gnome-session, moving per-user services that are in some way associated with the graphical login session from the login session itself into systemd units so that they can be managed by `systemd --user`. (Or, possibly, moving per-user services into activatable D-Bus services, which in turn end up being either systemd units or children of dbus-daemon's systemd unit or descendants of dbus-launch, depending how the system has been set up.) One effect of that design change is that orca needs to interact with the login-session/user-session duality[3] in ways that don't assume that it is necessarily still running inside the login session. smcv [1] technically two, one belonging to `systemd --user` and one to `dbus-daemon --session`, but it's usually a bug if they're different [2] https://gitlab.gnome.org/GNOME/gnome-session/-/blob/50.alpha/gnome-session/gsm-util.c?ref_type=tags#L40 [3] using the terminology from https://lists.freedesktop.org/archives/systemd-devel/2015-January/027711.html
