On Wed, Jan 25, 2023 at 03:44:26PM +0000, Daniel P. Berrangé wrote:
On Wed, Jan 25, 2023 at 04:39:31PM +0100, Martin Kletzander wrote:
> On Wed, Jan 25, 2023 at 04:06:49PM +0100, Martin Kletzander wrote:
> > On Wed, Jan 25, 2023 at 02:27:09PM +0000, Daniel P. Berrangé wrote:
> > > If libvirt is built in client only mode, the libvirtd/virtqemud/etc
> > > daemons won't exist. If the client is told to connect to a local
> > > hypervisor, it'll see the socket doesn't exist, try to spawn the
> > > daemon and then re-try connecting to the socket for a few seconds.
> > > Ultimately this will fail because the daemon doesn't exist and the
> > > user gets an error message
> > >
> > > error: Failed to connect socket to
'/run/user/1000/libvirt/virtqemud-sock': No such file or directory
> > >
> > > technically this is accurate, but it doesn't help identify the root
> > > cause. With this change it will now report
> > >
> > > error: binary 'virtqemud' does not exist in $PATH: No such file or
directory
> > >
> > > and will skip all the socket connect retries
> > >
>
> Actually, Michal had a good question, this should fail in virCommandRun,
> and looking at virExec it even does the virFindFileInPath if the first
> argument is not absolute and errors out if the path cannot be found.
> You might still get ENOENT when running the binary in case a linked
> library is missing or something and even without this check. I guess
> our double-fork() in virExec() might be at fault? When not using a
> pidfile there is no wait for the second child to let us know that it
> failed (or close the pipesync[1]). Maybe that is the root cause?
This in most cases virCommand would do the right thing in
reporting the missing binary.
In this specific case though, we're daemonizing the binary
we're spawning and letting it start asynchronously, so we
don't have a way to feed the ENOENT back from the child.
Oh, I get it, the binary is probably already an absolute path, so the
check is skipped in virExec(). Maybe virExec() should always do the
check with virFindFileInPath() and not just when the first argument is
not absolute. That would catch the same error more places.