On 2/17/25 3:11 PM, Laine Stump wrote:
On 2/17/25 5:28 AM, Daniel P. Berrangé wrote:
On Mon, Feb 17, 2025 at 02:14:49AM -0500, Laine Stump wrote:
But sometimes XDG_RUNTIME_DIR isn't set in the user's environment.
Do you have examples of scenarios in which this happens, and
yet the /run/user/NNNN directory is still being created, as
that rather sounds like something is broken outside of libvirt.
After seeing the bug report, I replicated the situation by ssh'ing in as
a user that hadn't previously logged in, and then unsetting
XDG_RUNTIME_DIR. I hadn't thought there might be some other case where
the user could be logged in but XDG_RUNTIME_DIR had never been set.
But after seeing your question I tried running
sudo $someuser virsh list
actually it was "sudo -u $someuser virsh list"
where $someuser was a user than hadn't logged in since the last host
reboot (and so therefore /run/user/$someuser-id didn't exist) and then
checking for /run/user/$someuser-id, and you're correct that it wasn't
created :-/ (and also :-) I guess)
Of course if that user had previously logged in "normally" since the
last host reboot, then that login session *would* create /run/user/
$someuser-id. So what I'm doing in this patch would help in some
situations, but not all (at least it doesn't make any situation *worse*
though - if /root/user/$id doesn't exist then it falls back to the
current behavior).
(As a matter of fact, it seems like we have a problem now that if
someone does login as userX o a normal session, starts up some guests,
and the virtqemud process is terminated for some reason and then later
they use "su userX virsh list" (or whatever) then the newly started
virtqemud will incorrectly look in $HOME/.cache to find the list of
currently active guests.)
So other than sticking with the current behavior and requesting an
SELinux change to allow us to use $HOME/.cache (which wouldn't solve the
problem in the previous paragraph), I suppose we could just decide
that /tmp/libvirt-${uid} shouldn't be used by anybody but us, and make
*that* our backup directory (maybe all the time so that it's consistent).
libvirt actually depends on the directory being cleared
out during a reboot - otherwise it might think that stale status files
are indicating active guests when in fact the guests were shutdown
during the reboot).
We could make our status files robust against host reboots by
storing "/proc/sys/kernel/random/boot_id" in them. If boot_id
has changed, we know the pidfile is stale.
I haven't checked if there is an *actual* problem of us believing stale
status files are valid (that was just an idle supposition on my part of
something that *might* be problematic due to using a misbehaving runtime
dir), but in general that sounds like a good idea (at least on Linux
systems). Doesn't solve the SELinux (and presumably AppArmor) problem
though...
(I guess I need to try something like
1) start a guest with "sudo $user virsh start blah"
2) restart the host
[we now have a $HOME/.cache populated with status files]
3) again use sudo $user to try several virsh commands that
would get info from status files to see if anything fails.
)
An example of the opposite that I tried - if I login as $someuser and
"virsh start blah", then separately (without rebooting the host) as a
different user I run "sudo -u $someuser virsh list", I will get back an
empty list (because 1) for some reason (also probably related to lack of
environment) a 2nd virtqemud process is started, and 2) the new instance
of virtqemud doesn't have XDG_RUNTIME_DIR set, so it's looking in
$HOME/.cache)
Fortunately this is only an issue for unprivileged libvirt, and most of
the drivers don't work unprivileged anyway (right? the only other driver
I've ever paid attention wrt to this was the network driver).
