Systemd user sessions in interactive desktop

hsmallbone · August 11, 2025, 4:09pm

I’m not sure if it’s an issue with our configuration but when users start an interactive desktop session (we use RHEL9 and TurboVNC) there is no associated systemd user session. This causes problems with for example podman, which requires a systemd user session. From investigating, one solution may be to add systemd run –user to this line in OOD core: ood_core/lib/ood_core/batch_connect/templates/vnc.rb at cf9f0c421a9029d150161356a96bb0714507eb24 · OSC/ood_core · GitHub

Before I do that was just wondering if this was expected behaviour or if there were any other experiences with this?

jeff.ohrstrom · August 11, 2025, 4:14pm

We’re not entirely sure. This was a community contribution that we (OSC) don’t use, so I’m not 100% sure here.

hsmallbone · August 11, 2025, 4:15pm

Should I look at contributing a setting for this? I don’t want to affect other user workflows.

jeff.ohrstrom · August 11, 2025, 4:31pm

Sorry, I’m confusing myself because I thought you’d meant the systemd adapter.

I guess I’d have to see what your proposed solution is. I know for us, we have to set XDG_RUNTIME_DIR for newer systems because we often can’t write to /var/run/$(id -u). Is that perhaps a symptom of the same issue you’re running into?

hsmallbone · August 11, 2025, 5:31pm

I’d probably start by trying systemd-run --user --scope to that line and seeing if anything else needs to be added further up the stack. We also have to set XDG_RUNTIME_DIR in some situations with podman.

djareval · August 12, 2025, 10:40pm

We previously came across this same issue.

Our solution was to handle the creation and lingering of user sessions through Slurm, using loginctl in the prolog and epilog scripts. It’s worked well at our site.

The Slurm documentation describes how:

hsmallbone · August 13, 2025, 8:56am

Thanks for the pointer. I have followed the steps there but still having the same issue unless I disable pam_systemd.so. Is it possible to only do this for ood-specific logins?

djareval · August 13, 2025, 11:59am

I’m not sure how you’d do that for just OOD logins.

But reviewing for a minute, what’s your indication that there’s no systemd user session? From a terminal in the VNC session, does loginctl user-status <username> show anything? (Ensure you specify the username to bypass whatever is set in $DBUS_SESSION_BUS_ADDRESS)

I’m also having an issue with podman over TurboVNC on RHEL 9, and I’m wondering if this is the same thing.
My problem: although there is a systemd user session, processes over the VNC session can’t see it because TurboVNC is setting a unique DBus.

hsmallbone · August 13, 2025, 12:16pm

Hmm, I think you’re right - I am having the same issue as in your post. I was checking with loginctl and assumed no session was set but if I include the username then I do see that there is a session with lingering enabled for my user.

Perhaps the solution would be to PR additional arguments to the TurboVNC invocation?

hsmallbone · August 13, 2025, 12:51pm

I tried adding -userdbus but it didn’t work. I’m not super familiar with TurboVNC workings however.

djareval · August 13, 2025, 1:09pm

I’m not sure what’s the best approach. Although TurboVNC has configurations to use the systemd user DBus, they’re ignored by the fact that OOD invokes vncserver with the -noxstartup option:

github.com/OSC/ood_core

lib/ood_core/batch_connect/templates/vnc.rb

master


      
          for i in $(seq 1 10); do
            # Clean up any old VNC sessions that weren't cleaned before
            #{vnc_clean}
          
            # for turbovnc 3.0 compatability.
            if timeout 2 vncserver --help 2>&1 | grep 'nohttpd' >/dev/null 2>&1; then
              HTTPD_OPT='-nohttpd'
            fi
          
            # Attempt to start VNC server
            VNC_OUT=$(vncserver -log "#{vnc_log}" -rfbauth "#{vnc_passwd}" $HTTPD_OPT -noxstartup #{vnc_args} 2>&1)
            VNC_PID=$(pgrep -s 0 Xvnc) # the script above will daemonize the Xvnc process
            echo "${VNC_OUT}"
          
            # Sometimes Xvnc hangs if it fails to find working disaply, we
            # should kill it and try again
            kill -0 ${VNC_PID} 2>/dev/null && [[ "${VNC_OUT}" =~ "Fatal server error" ]] && kill -TERM ${VNC_PID}
          
            # Check that Xvnc process is running, if not assume it died and
            # wait some random period of time before restarting
            kill -0 ${VNC_PID} 2>/dev/null || sleep 0.$(random_number 1 9)s

Whether setting $userDBus = 1 in the config file, or adding -userdbus as an option, you can see by walking through /opt/TurboVNC/bin/vncserver that those configs only come into play once TurboVNC runs the /opt/TurboVNC/bin/xstartup.turbovnc script. But with -noxstartup, it never gets run.

Possible question for @jeff.ohrstrom: is -noxstartup really necessary?
If so, then it’s probably a question for the TurboVNC developers: can -userdbus be decoupled from execution of xstartup.turbovnc?

hsmallbone · August 13, 2025, 1:38pm

Is it as simple as setting DBUS_BUS_SESSION_ADDRESS to $XDG_RUNTIME_DIR/bus?

EDIT: looks like no. I’ve also tried enabling xstartup which died since it expects a window manager to be provided. I also tried a blank xstartup script but also to no avail.

djareval · November 7, 2025, 3:07am

Hello, just following up after I had a chance to revisit this issue recently:

We identified a simple workaround by commenting out this line in /var/www/ood/apps/bc_desktop/template/desktops/xfce.sh:

github.com/OSC/ondemand

apps/bc_desktop/template/desktops/xfce.sh

9bdcf6c06


      
              CommandLoginShell=TRUE
          EOL
          else
            sed -i \
              '/^CommandLoginShell=/{h;s/=.*/=TRUE/};${x;/^$/{s//CommandLoginShell=TRUE/;H};x}' \
              "${TERM_CONFIG}"
          fi
          
          # launch dbus first through eval because it can conflict with a conda environment
          # see https://github.com/OSC/ondemand/issues/700
          eval $(dbus-launch --sh-syntax)
          
          # Start up xfce desktop (block until user logs out of desktop)
          xfce4-session

This prevents the creation of a duplicate DBus session, and the default systemd-created session at $XDG_RUNTIME_DIR/bus is then used.

hsmallbone · December 4, 2025, 7:35am

Thanks so much for sharing. Have implemented this fix as well.

Topic		Replies	Views
Configuring TurboVNC to utilize the user systemd DBus instance Get Help	2	133	November 7, 2025
XFCE interactive desktop for Rocky Linux 8 not working but worked just once Get Help question	5	904	January 10, 2024
Session briefly starts then immediately crashes; User authentication problem? Get Help ondemand2 , question	3	749	March 6, 2023
OOD apps stopped working Get Help	8	140	January 13, 2025
Error when connecting to interactive desktop Get Help	14	738	October 30, 2024

Systemd user sessions in interactive desktop

Related topics