Bug 885386 - libvirtd --timeout doesn't work
libvirtd --timeout doesn't work
Status: CLOSED CURRENTRELEASE
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-08 19:31 EST by Cole Robinson
Modified: 2016-04-26 15:33 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-09 14:34:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Cole Robinson 2012-12-08 19:31:57 EST
libvirtd --timeout 5
(wait forever, nothing happens)

and there's even some other weirdness here: --timeout=1  can't be killed with control-c, and it hangs qemu instances launched to fetch capabilities info. So something is probably firing behind the scenes but not doing a complete job.

--timeout=30 is used for autolaunching libvirt with qemu:///session, so this isn't entirely minor.
Comment 1 Daniel Berrange 2012-12-10 09:01:05 EST
In current libvirt releases, any active resource will block shutdown. eg if you have any active storage pools, networks, or domains, it will be blocked. A directory based storagepool is the usual issue, since those can't even be de-activated. Upstream code has completely changed so that only domains prevent shutdown.

The timeout=1/Ctrl-C issue might be related to the fact that startup of the virStateInitialize will still be taking place in another thread, which might be badly interacting with shutdown/timeouts. Upstream doesn't start the timeout until after initialization is complete now.
Comment 2 Cole Robinson 2016-03-09 14:34:07 EST
Seems long since fixed

Note You need to log in before you can comment on or make changes to this bug.