Allow to get an elogind user seat while running user services

[puchu]

I'm currently using user services for pipewire-pulse and wireplumber, which works, but allowing to stream music with bluetooth seems to need an elogind user seat.

loginctl shows after startup:
SESSION UID USER SEAT TTY STATE IDLE SINCE
1 1000 foo - - active no -
4 0 root - pts/1 active no -

trying to connect a device with bluetooth doesn't work as i get disconnected after a few seconds.

when i spawn an xorg session with sddm autologin

loginctl shows:
SESSION UID USER SEAT TTY STATE IDLE SINCE
1 1000 foo - - active no -
4 0 root - - active no -
6 1000 foo seat0 tty7 active no -

and now it's possible to connect with bluetooth and stream music.

I think without a elogind seat, the access rights for dbus are missing and bluez tells pipewire about the connected device with dbus.

Is there a way to get a seat with user services?

[navi-desu]

we do start a pam session, but we're probably missing something to have it be considered a seat, since i don't know what criteria logind uses for it. depending on those we may be able to get a seat for user sessions

also, do systemd --user sessions get a seat? that's a thing to consider

[schlusslicht]

Hello! I'm also facing this issue and I think it will pop up quite frequently in the future, as more OpenRC based distributions switch to the user services feature. As far as I can tell this is directly related to running, e.g., gnome through elogind alongside OpenRC user services.

In my case, the user servivce dbus gets pulled in as dependency of wireplumber/pipewire[-pulse] and started as child of the OpenRC user session, as opposed to the elogind session. I run Alpine Linux with this configuration and was able to work around it by "monkey patching" the OpenRC user service:

# /etc/conf.d/user
pam_usr=${RC_SVCNAME#*.}
pam_uid=$(id -u $pam_usr 2>/dev/null)

# verify user (this excludes gdm and any "non-user" session)
if [[ -d /home/$pam_usr && -f /run/systemd/users/$pam_uid ]]; then
	# source the "private" elogind session file
	. /run/systemd/users/$pam_uid
	export XDG_RUNTIME_DIR=$RUNTIME

	# grab on to existing elogind seat
	export XDG_SEAT=$SEATS

	# this is unnecessary, see comments below
	#export XDG_SESSION_CLASS=user
	#export XDG_SESSION_ID=$SESSIONS
	#export XDG_SESSION_TYPE=wayland

	# this is incorrect but "works for me"
	#export XDG_VTNR=${TERM#vt10}
else
	# consider any "non-user" login a successful no-op
	exit 0
fi

# for verified users: move all OpenRC cgroup pids to the elogind cgroup
# .. there must be a better way
start_post() {
	while read PID; do
		echo $PID >/sys/fs/cgroup/$SESSIONS/cgroup.procs
	done <$rc_cgroup_path/cgroup.procs
}

The main underlying issues, that this "hack" works around, are:

1. multiple cgroups per login session
   The OpenRC user session service creates, as any OpenRC service, a cgroup named user.$USER, while elogind creates its own cgroup per session, named c$COUNTER (with the counter just being an per-session incremented integer, starting with 1). This results in certain checks within elogind to fail. E.g., if the DBus service runs within a different cgroup than elogind, elogind prohibits connections to its DBus power management features, which results in the "gnome display brightness quick setting slider" being defunctional.
2. missing OpenRC login "seat"
   (Beware, this is just pure speculation, I haven't traced down the code-paths within elogind to negate or validate the following assumptions.) Due to the OpenRC user session process(es?) not containing at least the environment variables XDG_SEAT and XDG_VTNR, it is not considered part of the main elogind session process or "seat". This results in the multiple sessions shown by loginctl, while only the elogind session is considered "seated".

I furthermore think that there is some kind of interaction through different involved PAM services; I've noticed that my gnome-keyring-daemon, which is started by pam_gnome_keyring.so, has the XDG_SEAT and XDG_VTNR environment variables set, which lead me to inspect the pam_elogind module, which indeed sets those.

Please be aware, this patch is more hit/miss than anything. In my setup, I didn't even need to activate OpenRC user services until I switched to pipe/wire/plumber, which resulted in broken audio on one of my devices (I guess a timing issue). I think a proper fix could be for OpenRC to allow overriding the serivce cgroup name (which seems possible by editing the rc-cgroup.sh; the rc_cgroup_path variable is a remnant from that script, possibly an unwanted one) and perhaps detecting the selected "seat" per PAM environment, but I'm no expert in any of the involved codebases.

Edit: Just found this, elogind/elogind@d21a97a, unsure what it means. :)

[navi-desu]

okay this will be... difficult.

for cgroups, i plan to have openrc.user delegate a cgroup subtree to user services -- so that we can track services via cgroups like that-- this obv mean it conflicts with elogind wanting services to be in it's own c$counter group

seat and tty is another issue. setting tty would be just, wrong. user services don't have a tty, they're spawned in the background by design. seat is trickier because it really depends on what services are or will be ran... can't tell at a glance what we should do there

hmmm... i'll research more

[schlusslicht]

Hello and thank You for Your quick reply! I'm also still investigating this and noticed the following without applying "my hack":

# as assumed:
cat /sys/fs/cgroup/openrc.user.$USER/cgroup.procs | sed 's|.*|/proc/\0/cgroup|' | xargs cat
# 0::/openrc.user.$USER

# but:
pgrep -U $(id -u $USER) /usr/bin/dbus-daemon | sed 's|.*|/proc/\0/cgroup|' | xargs cat
# 0::/c2
# 0::/c2

# with:
loginctl --no-legend list-sessions 
# c1 1000 $USER seat0 tty2
# c2 1000 $USER

# and:
rc-status -U | cat
# Runlevel: default
#  wireplumber                                  [  started ... (1) ]
#  pipewire                                     [  started ... (0) ]
#  pipewire-pulse                               [  started ... (0) ]
# Dynamic Runlevel: hotplugged
# Dynamic Runlevel: needed/wanted
#  dbus                                         [  started ... (0) ]
# Dynamic Runlevel: manual

So it seems that all processes spawned by the OpenRC user session are somehow already transferred to the (correct) elogind cgroup? I'm not sure how this happens and I'm quite sure, that I needed to manually transfer the processes between cgroups on one of my devices (or I couldn't control the backlight brightness through the "gnome display brightness quick setting slider"). I'll have to investigate further, but thought I'd share this early finding.

Update

The culpit here seems to be an interaction between seat- and cgroup-assignment by elogind; when I only set the the XDG_SEAT and XDG_VTNR environment variables through /etc/conf.d/user, all processes spawned by the OpenRC login session service remain children of its cgroup. Which means, this actually works as intended? I'll try to replicate the broken behaviour on the device which initially lead me to try to fix this seemingly non-issue.

Update

Ok, I think I've nailed down my use-case. The broken behaviour is only exhibited by a device running the gnome-shell-mobile fork, which includes lots of changes to power handling features etc. That's why on my other devices the backlight control works fine, while on this particular device, I'm running into the following issue:

# dbus-monitor --system # while using the "gnome display brightness quick setting slider"
method call sender=:1.69 -> destination=:1.4 serial=126 path=/org/freedesktop/login1/session/auto; interface=org.freedesktop.login1.Session; member=SetBrightness
   string "backlight"
   string "backlight"
   uint32 178
method call sender=:1.4 -> destination=org.freedesktop.DBus serial=1237 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=GetConnectionUnixProcessID
   string ":1.69"
method return sender=org.freedesktop.DBus -> destination=:1.4 serial=636 reply_serial=1237
   uint32 4426
error sender=:1.4 -> destination=:1.69 error_name=org.freedesktop.login1.NotYourDevice reply_serial=126
   string "Your session has no seat, refusing."

My other devices seem to be using a more elaborate method to set the display backlight brightness, involving calls to polkit etc. But there are other side-effects of this setup (i.e., running OpenRC user services alongside elogind), like the one the OP of this issue described or my inability to decrypt devices, if I don't provide the XDG_SEAT and XDG_VTNR environment variables to the OpenRC user service/login session.

Regarding Your reply,

seat and tty is another issue. setting tty would be just, wrong. user services don't have a tty, they're spawned in the background by design. seat is trickier because it really depends on what services are or will be ran... can't tell at a glance what we should do there

I guess You are talking about the XDG_VTNR environment variable? When I only assigned the XDG_SEAT environment variable to the OpenRC login session, I'm seeing this in the logs:

authpriv.err : pam_elogind(openrc-user:session) Failed to create session: VT number out of range

But You are corret as in, theres no other imminent issue I'm facing, so my original /etc/conf.d/user file can be trimmed down; I've edited my comments accordingly.

To summarise the observed behaviour (as good as I'm able to): elogind seems to check for the environment variable XDG_SEAT to assign a login session (/process?) to an existing seat. If I trick elogind to assign the OpenRC user session to the same seat as it created for my gnome session (necessary to make some priviledge checks go through, esp. for DBus-activated services), it assumes the OpenRC user session is also part of its (elogind) login session and that all processes are already in the correct cgroup (which it wouldn't, were the XDG_SEAT environment variable absent).