qubes.WaitForSession emits an error `Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined`

[ArrayBolt3]

How to file a helpful issue

Qubes OS release

R4.3

Brief summary

In all templates (at least the ones I've tried; debian-13-xfce, fedora-42-xfce, and whonix-gateway-18), there is an error message in the output of sudo journalctl --boot matching the title. This appears to be coming from /etc/qubes-rpc/qubes.WaitForSession.

Steps to reproduce

1. Boot fedora-42-xfce.
2. Run sudo journalctl --boot
3. Search for Failed to connect to user scope bus
4. See error
5. Run sudo vim /etc/qubes-rpc/qubes.WaitForSession
6. Replace the line systemctl --user --wait --quiet is-system-running with the following:

logger "$$: $(id)"
systemctl --user --wait --quiet is-system-running || {
  logger '$$: failed here'
}
logger "$$: made it"

7. Reboot the template.
8. Run sudo journalctl --boot in the template.
9. Search for failed here, and observe that the service is failing when called as root, but succeeds when called as user, based on the logger output from earlier.

Expected behavior

qubes.WaitForSession should never emit any errors.

Actual behavior

qubes.WaitForSession is emitting the aforementioned error when called as root.

Additional information

I tried making the following modification to qubes.WaitForSession in whonis-gateway-18, but while this did fix the error message, it also made it so that if one attempts to launch a GUI app in the qube while it is not yet booted, the qube will boot without issues, but the app will never launch. Subsequent attempts to launch GUI apps succeed.

logger "$(id)"

logger "trying... $$"
if [ "$(id -u)" = '0' ]; then
  systemctl --wait --quiet is-system-running
else
  systemctl --user --wait --quiet is-system-running
fi

logger "made it! $$"

This showed that it took about 9 or 10 seconds from the time that root showed a trying: PID message to the time that root showed a made it! PID message (with the PID values matching in both locations). The first GUI app I attempted to launch never showed up, not even after twenty seconds.

The following modification seems to get rid of the error message and keep the previous behavior, but I'm not sure if it's correct since it means that qubes.WaitForSession may return before the system is "fully booted" (which is what the current, unmodified code does also):

if [ "$(id -u)" = '0' ]; then
  exit 0
else
  systemctl --user --wait --quiet is-system-running
fi

[ben-grande]

9. Search for failed here, and observe that the service is failing when called as root, but succeeds when called as user, based on the logger output from earlier.

Sure, because it is waiting or the user scope/space of systemd. The problem is the caller requesting the root user. We don't care if the root user systemd is ready, we care about the default user. Why is the call using the root user?