Virt-manager doesn't work after install before a reboot

[Pedro Côrte-Real]

Right after installing virt-manager running it results in an error about not being able to access the system daemon. This is fixed after a reboot.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: virt-manager 1:1.5.1-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Aug 1 15:07:16 2018
InstallationDate: Installed on 2018-05-31 (62 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
PackageArchitecture: all
SourcePackage: virt-manager
UpgradeStatus: No upgrade log present (probably fresh install)

[Christian Ehrhardt  (paelzer)]

Hi Pedro,
If you had no libvirt installed at all then your user will - after install - not have the group "libvirtd" yet.

A simple relogon or any new session would do to get that.
Even some su - tricks could do so, but TL;DR I assume you are just not yet a member of the group.

Obviously a reboot is the hardest way of "re-logging in" :-/

This is a common pattern - for example on a new system installing "lxd" you will not be able to use it right away not having the LXD group, but relogging to refresh groups makes it work.

I'm not sure there is a lot I can do about it.
If there is a good way to do so I'd be happy to lean about it. But then IMHO all packages adding default group memberships should do so and that sounds like a dh_ helper then.
You are welcome to extend the bug to debhelper, but I'd think a mail to ubuntu-devel mailing list might be more appropriate to start an open discussion.

Setting incomplete, would be happy to hear if my assumption of the group membership is your case.
If not lets check what else it is - maybe starting with "sytemctl status libvirtd" and "id" after installing the packages.

[Pedro Côrte-Real (pedrocr)]

In my case it's almost surely the group membership issue. I found that online and just rebooted in case there was something else that needed to be brought up properly. Better safe then sorry. At the very least the error message should be better but there should be a way to actually fix this. It's not common to install an app and need to re-login to be able to use it. Makes for quite a strange user experience.

[Christian Ehrhardt  (paelzer)]

> It's not common to install an app and need to re-login to be able to use it. Makes for quite a strange user experience.

In fact it is common enough, just most of the other cases are pre-installed so people never recognize it. But if you start with a minimal image you'll hit a few.

> At the very least the error message should be better

The message currently should be like "Can't access /var/run/libvirt/libvirt-sock" or something like it right?
What would be a good addition there, maybe "Please ensure that you can access the file (group permissions)"

Since libvirt/virt-manager can have so many connections - local socket, remote systems, different types - it is hard to have a good message.

Instead we could think of a message on-install that echoes like "If you are going to use this please re-log to pick up the new group membership". But TBH lessons-learned people don't read what is printed on the console on install.

> but there should be a way to actually fix this.

Re-log (or a new) session that starts e.g. virt-manager is enough - so there is a way to fix it.

[Christian Ehrhardt  (paelzer)]

I wanted to see the effect myself, so I set up a new system and triggered the issue.
Message is:
"
Unable to connect to libvirt qemu:///system.

Verify that the 'libvirtd' daemon is running.

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1036, in _do_open
    self._backend.open(self._do_creds_password)
  File "/usr/share/virt-manager/virtinst/connection.py", line 144, in open
    open_flags)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 105, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied
"

The same applies to commandline tools like
$ virsh list
error: failed to connect to the hypervisor
error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': Permission denied

As I assumed - re-logging the user works fine and resolves the issue.

[Christian Ehrhardt  (paelzer)]

I knew this seemed somewhat known to me, it turns out I tried to work on it once already.
But due to translations this would be a (unreasonably) huge Delta for any Distributions to carry.
Just to say instead of:
  Verify that the 'libvirtd' daemon is running.
like:
  Verify that the 'libvirtd' daemon is running - if libvirt was just installed you might miss the group permission and might need to login the session starting this program.

We might be fine if that change is upstream, avoiding that everybody has to carry the 100 translation change, but then still I think it isn't a big deal.

Please feel free to report upstream for a modification of the message if you think it would really help users.

[Christian Ehrhardt  (paelzer)]

There are plenty of discussions on the topic in general around all of linux, like:
- https://superuser.com/questions/272061/reload-a-linux-users-group-assignments-without-logging-out
- https://serverfault.com/questions/74934/refresh-supplementary-group-memberships-without-logging-in-again
- https://unix.stackexchange.com/questions/18796/how-to-apply-changes-of-newly-added-user-groups-without-needing-to-reboot

But none of the solutions there (sudo su / su / newgrp) would be safe to do from a package install POV - and furthermore none of these would e.g. fix your desktop environment around the shell that did the install.

As I said maybe there is a mechanism that I don't know, so maybe it is worth asking the mailing list.
I'll ask on the mailing list if I miss a mechanism to do this better.

[Christian Ehrhardt  (paelzer)]

FYI - polled for experience and opinions on the ML: https://lists.ubuntu.com/archives/ubuntu-devel/2018-August/040408.html