On 8/8/20 10:44 AM, Ken Swenson wrote:> Hello,
>
> I'm having a quite odd issue with libvirtd. I have it set to start on
> boot via systemd service, however it seems to fail and the service
> 'succeeds' and does not continue running the daemon. There is
nothing in
> the journal logs however the libvirtd debug logs seem to show
>
> 2020-08-08 13:55:26.362+0000: 1386: debug : virCommandRunAsync:2619
> : About to run ip link set lo netns -1
> 2020-08-08 13:55:26.362+0000: 1386: debug : virFileClose:134 :
> Closed fd 26
> 2020-08-08 13:55:26.362+0000: 1386: debug : virFileClose:134 :
> Closed fd 28
> 2020-08-08 13:55:26.362+0000: 1386: debug : virFileClose:134 :
> Closed fd 30
> 2020-08-08 13:55:26.362+0000: 1386: debug : virCommandRunAsync:2621
> : Command result 0, with PID 1610
> 2020-08-08 13:55:26.390+0000: 1386: debug : virCommandRun:2461 :
> Result fatal signal 2, stdout: '' stderr: 'RTNETLINK
answers: No
> such process
>
> I am not sure if this is relevant to the problem or not as I do not see
> anything else in the logs that indicates an issue during the launch
> process, other than many file descriptors closing but I assume that is
> normal. If I then start libvirtd a second time after it has been
> launched once it runs fine. I don't believe it is a race condition on
> boot as if I disable the auto start and manually start it it will still
> fail in the same way the first time.
>
> If anyone has any ideas on what I may be able to check to fix this I
> would really appreciate it. It has been bugging me for some time now.
The command "ip link set lo netns -1" is called by the LXC driver
(during its driver init) as a check to see if the OS supports network
namespaces. This is done in the function lxcCheckNetNsSupport(), which
was added to libvirt's LXC driver in commit 99ded85f4 in 2008, has 0
comments about how it works, and has been functionally unchanged since then.
It appears that on your system for whatever reason the attempt to send
the netlink message that sets the netns for lo to -1 fails the first
time it is run, causing lxcCheckNetNsSupport() to return false. I don't
see how this would cause libvirtd to exit though (I *guess* that's what
you're saying happens?). I'm guessing this is a red herring.
What is the practical problem you have? After this "success" are you
not
able to start guests or run commands with virsh? Or were you just
surprised that the libvirtd process wasn't there when you looked? If the
latter, that could be due to using socket activation - libvirtd is no
longer running all the time; systemd sets up the listening sockets and
starts libvirtd when needed; if 120 seconds go by and there are no
guests running and no management clients connected to libvirtd, then it
will automatically exit.
(BTW, I'm probably the least knowledgeable person about kernel
namespaces around, but I thought that all Linux systems have had
namespace support for a very long time. Does anybody ever actually
disable it? Do we really need this check?)
