On 07/25/2012 10:30 PM, Eric Blake wrote:
On 07/25/2012 06:43 AM, Guannan Ren wrote:
> Only when there is no running guest, virtual network, etc on each
> registered drivers and no client connections, the timeout take effect.
>
> ---
> daemon/libvirtd.pod.in | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/daemon/libvirtd.pod.in b/daemon/libvirtd.pod.in
> index ea6c37d..75c9040 100644
> --- a/daemon/libvirtd.pod.in
> +++ b/daemon/libvirtd.pod.in
> @@ -54,7 +54,7 @@ Use this name for the PID file, overriding the default value.
>
> =item B<-t, --timeout> I<SECONDS>
>
> -Exit after timeout period (in seconds) expires.
> +When there is no any active resources on each registered driver and client
connections, exit after timeout period (in seconds) expires.
Long line needs wrapping. Also, I think it reads slightly better as:
Exit after timeout period (in seconds) elapse with no client connections
or registered resources. Be aware that resources such as autostart
networks will result in never reaching the timeout, even when there are
no client connections.
And stepping back and looking at the issue from a different point of
view, WHY do we refuse to exit if there are autostart networks?
Basically, the 'default' network means that the timeout option is
worthless on an out-of-the-box Fedora install. Should we re-purpose the
--timeout parameter to exit when there are no client connections,
without regards to whatever other autostart resources exist? But that's
a bigger change to libvirtd.
During my try to use it, it is, the same situation happens on
nwfilter and storage
driver. It has to deactivate all of these running resources
including default.
According to the comment 1 from Daniel in BZ831049,
"The timeout option is primarily intended for use with the
non-privileged libvirtd
when it has been auto-spawned by a client app."