Hello again, in the meantime, I have done some reading up on the sd-login man page and related documents and specs from there. Still, I am not much wiser as to how services are supposed to figure out what session they should serve. In fact, it seems to me that services are conceptually orthogonal to sessions.
But is it really so unnatural to think that certain processes should be tied to a particular session? Wouldn't it make sense to let some manager in the scope of that particular session launch those processes rather than the general session manager start them as services? Otherwise, it seems to me that processes in the slice of a service unit have a hard time figuring out what session scope may have asked the session manager to start the service in the first place. Even loginctl can be fooled up to a point it seems. Switching away from a running Wayland session to the text console on tty2, the output of: $ loginctl session-status is as expected: Session type=tty, tty=tty2, state=active, and Unit=session-4.scope. Next, I launched the multiplexer tmux on tty2 and ran: $ loginctl session-status again. This time, it reported session type=wayland, tty=tty1, state=online, and Unit=session-5.scope. According to the man page, loginctl should have reported the status of the „current session“ in both cases but in the latter case it seemed to have an odd idea what the current session would be. Anyway, back to the original problem: How should Orca determine the session that it is supposed to manage the braille display for? Please see below for more inline. On 2026-01-15 at 08:24:14 (+0100), Elias Oltmanns <[email protected]> wrote: > Hi Adrian, > thank you very much, this has been useful to me. I do have some > questions inline: > > On 2026-01-14 at 08:35:15 (+0100), Adrian Vovk <[email protected]> wrote: >> Hello all, >> I have some thoughts to add, in no particular order. >> >> * Running Orca as part of the systemd --user session is unequivocally the >> right thing to do, and going back to the way it was before is no longer >> possible anyway. The code that used to do that is gone and there's no easy >> way to bring it back. >> >> * Having more than one activation environment is interesting. OpenRC is >> experimenting with a model where services declare what variables they want >> to pull in from their dependencies. I think a separation between GUI and >> non-GUI activation environments might be more practical. But I don't think >> this is the underlying source of the problem >> >> * The ideal immediate term solution here is for Orca to query the TTY of >> the current logind session it's running on, and then pass that along. Note >> that not all sessions are attached to a TTY - Orca will need to handle that >> too. > > May be, its because I still have a limited understanding of CGroups, > seats, sessions, etc. How exactly do I, or rather would Orca figure out > what logind session it is running on? My confusion comes from studying > the output of systemd-cgls. When I enable gdm and start a session there, > the hierarchy looks something like this: > > ├─user.slice > │ └─user-1000.slice > │ ├─[email protected] … > │ │ ├─session.slice > │ │ │ ├─gvfs-goa-volume-monitor.service > │ │ │ │ └─3883 /usr/lib/gvfs-goa-volume-monitor > │ │ │ ├─orca.service > │ │ │ │ └─3619 orca > [...] > │ └─session-4.scope > │ ├─2909 gdm-session-worker [pam/gdm-password] > │ ├─3239 /usr/lib/gdm-wayland-session /usr/bin/gnome-session > │ └─3243 /usr/lib/gnome-session-init-worker gnome > > Please note that session-4.scope really is that short, I have not > clipped anything there. Pretty much everything is happening beneath > [email protected] and that is where Orca is, too. So is Orca related to > a logind session in some way and how can that be queried? Or needs Orca > to be started differently in order to make sure that it appears under > session-4.scope? > >> >> * Orca should not continue relying on the existence of XDG_VTNR in the >> long term. There have been ongoing experiments for years now to have >> desktop Linux function with the entire VT subsystem disabled. This >> means that XDG_VTNR would be empty because the concept of a VT >> wouldn't exist anymore on these systems. Most of the stack has been >> ported to work in this environment, so while I won't say CONFIG_VT=n >> is imminent, it's definitely on the horizon >> > [...] >> But ultimately: Orca should be able to tell BrlTTY "I'm running on session >> 22" and BrlTTY should monitor session 22 through logind. That's the only >> way for this bug to not return when distros start to flip CONFIG_VT=n. > > But am I right in thinking that Orca really is not running on session 22 > right now? It is started as a user.service and not tied to any > particular session as my example above seems to demonstrate. Alright, we do have API calls to list all sessions and can then go for the one with a session type known to be supported by Orca. But this feels not quite right because it relies on assumptions instead of being explicit. Is there a way to communicate to Orca in some way what session requested the start of the Orca service in the first place? Thank you in advance and best wishes, Elias
