I'd like to add something of this one, for future reference. It is easy to reproduce the issue on an Ubuntu system (your laptop), taking autopkgtest out of the equation. I'll outline steps to reproduce here below. I'll assume passwordless sudo and passwordless ssh for $USER@localhost.
### "sudo su" from a terminal ### This akin to using autopkgtest-virt-qemu, which connect to the VM via a serial console. From a terminal (gnome termina, tilix, ...), run $ env | grep XDG_RUNTIME XDG_RUNTIME_DIR=/run/user/1000 $ sudo env | grep XDG_RUNTIME [no output] $ sudo su paride -c env | grep XDG_RUNTIME XDG_RUNTIME_DIR=/run/user/1000 See how the first "sudo" cleans the XDG_ variables, but then su reattaches to the user session, and the XDG variables are back. ### "sudo su" via ssh ### We do the same as above, but via ssh: $ ssh localhost -- env | grep XDG_RUNTIME XDG_RUNTIME_DIR=/run/user/1000 $ ssh localhost -- sudo env | grep XDG_RUNTIME [no output] $ ssh localhost -- sudo su paride -c env | grep XDG_RUNTIME [no output] Note the no output in the latest command, and how that's different in the terminal session. This is the root of the problem. ### end ### On why that happens, there are a bunch of useful pointers here: https://unix.stackexchange.com/questions/346841/why-does-sudo-i-not-set- xdg-runtime-dir-for-the-target-user Looks like a way to get the user session back when using the ssh->sudo->su path is using machinectl, but we can't replace su with machinectl in autopkgtest. But perhaps machinectl can be used within the existing test to get the user session from within the test script. -- You received this bug notification because you are a member of Canonical's Ubuntu QA, which is subscribed to Auto Package Testing. https://bugs.launchpad.net/bugs/2103695 Title: autopkgtest runner does not run a systemd user instance Status in Auto Package Testing: Won't Fix Bug description: Both autopkgtest-virt-lxd and autopkgtest-virt-qemu, as well as debian's infra autopkgtest runners, have a systemd user session instance running during the test; this is evidenced by the fact that `$XDG_RUNTIME_DIR` is set, and you can talk to it with `systemctl --user` commands. Ubuntu's infrastructure instead does not have a systemd user instance running, creating a divergence in the test environment. Here's the most minimal reproducer: dget https://launchpad.net/~aleasto/+archive/ubuntu/tests/+sourcefiles/empty/1.0/empty_1.0.dsc autopkgtest ./empty_1.0.dsc -- qemu autopkgtest-plucky-amd64.img where autopkgtest-plucky-amd64.img is generated by autopkgtest- buildvm-ubuntu-cloud. The test runs the following script: echo "XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR" systemctl --user status The test passes locally, but not on ubuntu's infrastructure. Here's a log from my ppa: https://autopkgtest.ubuntu.com/results/autopkgtest-plucky-aleasto-tests/plucky/amd64/e/empty/20250319_161854_94e24@/log.gz Expected result: autopkgtest [10:03:00]: test test-systemd-user: [----------------------- XDG_RUNTIME_DIR=/run/user/1000 ● autopkgtest State: running Units: 133 loaded (incl. loaded aliases) Jobs: 0 queued Failed: 0 units Since: Thu 2025-03-20 10:03:01 CET; 136ms ago systemd: 257.4-1ubuntu1 Tainted: unmerged-bin CGroup: /user.slice/user-1000.slice/user@1000.service └─init.scope ├─15648 /usr/lib/systemd/systemd --user └─15650 "(sd-pam)" Actual result: autopkgtest [16:18:34]: test test-systemd-user: [----------------------- XDG_RUNTIME_DIR= Failed to connect to user scope bus via local transport: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user) To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/2103695/+subscriptions -- Mailing list: https://launchpad.net/~canonical-ubuntu-qa Post to : canonical-ubuntu-qa@lists.launchpad.net Unsubscribe : https://launchpad.net/~canonical-ubuntu-qa More help : https://help.launchpad.net/ListHelp
