On our RHEL 9 system, we have been dealing with an issue on interactive desktops where podman has limited utility, we see warnings like:
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to log in using a user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 70621` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs
We handle user session lingering through Slurm, so that’s not the problem. Rather, it’s because TurboVNC creates and uses a unique DBus sessions in /tmp, rather than the systemd user instance at $XDG_RUNTIME_DIR/bus:
This appears to be expected behavior, and TurboVNC can be configured to utilize the user systemd bus: I could add -userdbus to the extra_args: key in the submit.yml.erb file or set $userDBus = 1; in /etc/turbovncserver.conf.
However, the way in which TurboVNC is called by the OOD interactive app precludes that: the user DBus options are never read due to how the vncserver and xstartup.turbovnc scripts execute when using the -noxstartup option.
Has anyone else come across this issue? Any recommendations for how we might effectively direct TurboVNC to use the user systemd DBus instance?
I’m not 100% sure what could be done here without a lot of investigation into systemd, dbus, and TurboVNC.
That said - you can supply an initializer to redefine behavior entirely if you want to get rid of that flag. Here’s what I’ve got working as an example. You place the file at /etc/ood/config/apps/dashboard/initializers/vnc_patch.rb (you can rename the file if you like, the directory is the important bit).
I’ve added the line echo 'made it here with these edits!' to ensure that this is the code that’s being executed and not the one that we shipped with OOD.
# /etc/ood/config/apps/dashboard/initializers/vnc_patch.rb
require 'ood_core/batch_connect/templates/vnc'
Rails.application.config.after_initialize do
OodCore::BatchConnect::Templates::VNC.class_eval do
private
def before_script
<<-EOT.gsub(/^ {14}/, "")
# Setup one-time use passwords and initialize the VNC password
function change_passwd () {
echo "Setting VNC password..."
password=$(create_passwd "#{password_size}")
spassword=${spassword:-$(create_passwd "#{password_size}")}
(
umask 077
echo -ne "${password}\\n${spassword}" | vncpasswd -f > "#{vnc_passwd}"
)
}
change_passwd
# Start up vnc server (if at first you don't succeed, try, try again)
echo "Starting VNC server..."
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
echo 'made it here with these edits!'
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
# If running, then all is well and break out of loop
kill -0 ${VNC_PID} 2>/dev/null && break
done
# If we fail to start it after so many tries, then just give up
kill -0 ${VNC_PID} 2>/dev/null || clean_up 1
# Parse output for ports used
display=$(echo "${VNC_OUT}" | awk -F':' '/^Desktop/{print $NF}')
port=$((5900+display))
echo "Successfully started VNC server on ${host}:${port}..."
#{super}
EOT
end
end
end
Following up on this, it appears that modifying how vncserver launches is not the right fix. The fact that -noxstartup prevents the xstartup.turbovnc script from executing simply prevents TurboVNC from setting or modifying $DBUS_SESSION_BUS_ADDRESS.
The culprit is the xfce.sh script (installed at /var/www/ood/apps/bc_desktop/template/desktops/) which initially launches a DBus session here:
Manually launching a DBus like that seems to be unnecessary, since systemd apparently launches one for the user at login. Commenting out that line does the trick: the VNC session starts with no issue, $DBUS_SESSION_BUS_ADDRESS points to the systemd-default instance at $XDG_RUNTIME_DIR/bus, and the podman warnings are gone.
Note that we haven’t extensively tested this yet, it may negatively impact multiple sessions; from the xstartup.turbovnc script:
…the per-user D-Bus session bus instance provided by systemd… improves cgroup v2 compatibility at the expense of multi-session capability.