creation of session service type

[akarl10]

Component

systemd, systemd-logind

Is your feature request related to a problem? Please describe

currently if a user logs and pam_session includes systemd, then a user session is created. If a user logs in multiple times that user services are shared. This is however a issue if a virtual graphical session is started an for example pulseaudio or pipewire are shared. A better solution would be if every session would have its own service scope and only user services that are really shareable run under the user global scope.

Describe the solution you'd like

create a XDG_RUNTIME_DIR for every session, not user. for dbus services that run under user global scope something like xdg-dbus-proxy probably would be a interim solution, but a cleaner solution would be the introduction of another DBUS environment variable, like
DBUS_SESSION_BUS_ADDRESS session (existing, but would point to ex. /run/user/$UID/$SESSIONID/bus)
DBUS_USER_BUS_ADDRESS user global (new, would point to /run/user/$UID/bus)
DBUS_SYSTEM_BUS_ADDRESS system global

until application know DBUS_USER_BUS_ADDRESS we would, like mentioned, need to proxy from SESSION to USER

as a bonus it would be cool if virtual seats would be created where such sessions could be bound

Describe alternatives you've considered

currently I do part of the above with a startscript in xrdp, but since no proxy is implemented some applications have problems.
also the list of services needed for a session is hand made, which is less than ideal. Here a snippet form the ugly script:

if [ "$XDG_RUNTIME_DIR" = "/run/user/"`id -u` ]; then
  export XDG_RUNTIME_DIR=/run/user/`id -u`/xrdp-` echo $DISPLAY | sed 's/:/display-/g' `
  mkdir -p $XDG_RUNTIME_DIR
  chmod 0700 $XDG_RUNTIME_DIR
  test -e $XDG_RUNTIME_DIR/systemd || ln -s "/run/user/"`id -u`/systemd $XDG_RUNTIME_DIR/systemd
  if [ "$XDG_SESSION_ID" != "" ]; then
    # used by reconnect.sh
    echo $XDG_SESSION_ID > $XDG_RUNTIME_DIR/login-session-id;
  fi
fi


if [ "$DBUS_SESSION_BUS_ADDRESS" = "unix:path=/run/user/"`id -u`"/bus" ]; then
  export DBUS_USER_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
  export DBUS_SESSION_BUS_ADDRESS="unix:path="$XDG_RUNTIME_DIR"/bus"
  dbus-daemon --session --fork --address=$DBUS_SESSION_BUS_ADDRESS --print-pid=3 3> "$XDG_RUNTIME_DIR/bus.pid"
  while [ ! -e "$XDG_RUNTIME_DIR/bus.pid" ] ; do sleep 1 ; done
  pulseaudio --start --use-pid-file
  pipewire &
  echo $! > "$XDG_RUNTIME_DIR/pipewire-0.pid"
fi

The systemd version you checked that didn't have the feature you are asking for

No response

[Marco-Gtto]

This is an actual issue with remote sessions. This RFE proposal could be a solution and should be considered in a timely manner

[akarl10]

calling that a solution is a bit early since for example gnome would need to adapt, but I think if we would have the possibility to make session services and user services the solution what is what should be straight forward for them (everything connected to the display/sound/input is session, settings daemons (probably), sync daemons would be user services). After that user interface tools should try to reach user services through XDG_USER_BUS_ADDRESS if available and fallback to XDG_SESSION_BUS_ADDRESS

Again, this issue is intended to start a discussion how true graphical multisession (+ optional multiseat) with the same account could be done in a clean way. Systemd has already the concept of multiple seats and multiple sessions, even for users, but desktop environments tend to make the assumtion user=session, probably because of the absence of session=session.

A problem with multiple seats from the same user might be with udev/uaccess, but this could probably solved with dynamic groups and assigning that to the session as aux group (if that is it possible in pam session, this should be quite easy. if it requires on pam auth, then it is tricky)

[poettering]

Sorry, but this is not going to happen. logind is specifically designed to maintain per user state and per-session state. user@.service is per user, not per session, and this is not going to change. sorry.

[akarl10]

Well, I don't expected to change user@.service but introduce a session@.service
As you said logind already knows what a session is, so I thought it might be possible to do that (altough I don't know how much work and I don't really know how logind says systemd to create a user slice and user@.service)

If such a type would exist I think gnome would launch its services with the session, not the user.
This, as said above, I think is the biggest issue