[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] ioemu-remote: check shutdown_requested timely.



Ian Jackson wrote:
> Cui, Dexuan writes ("[Xen-devel] [PATCH] ioemu-remote:
>> After a recent merge of the ioemu-remote tree several weeks ago, I
>> find in main() -> termsig_seup(), ioemu sets a SIGHUP handler that
>> sets a global variable shutdown_requested to 1, but ioemu doesn't
>> check the variable and as a result, ioemu wouldn't terminate when
>> xend sends a SIGHUP to it; finally xend has to send a SIGKILL to it
>> in 10 seconds. The small patch adds a check to terminate ioemu
>> timely.
> 
> I can reproduce the problem you report here - the symptoms I see are
> log messages in xend.log and that `xm destroy' is slow.
> 
> But while it's true that the main loop in vl.c doesn't check
> qemu_shutdown_requested, that main loop is not compiled in in qemu-dm.
The vl.c: main_loop() checks qemu_shutdown_requested but we don't use it; what 
we use is helper2.c:main_loop() which doesn't exit() when the variable is 1.

> Did you test your fix ?  Your fix would also seem to make qemu-dm exit
> immediately if the domain powers off even if on_poweroff=preserve.
Yes, I tested it and don't meet with the issue you mention. I think when we 
specify 'on_poweroff=preserve' in hvm config file, xend wouldn't send SIGHUP to 
ioemu at all when guest itself powers off normally.

> The root cause of the problem seems to be that upstream qemu installs
> signal handlers for the common terminating signals, which simply
> request shutdown.  That's not appropriate for us because xend sends us
> a signal when it wants us to really die.  So I have disabled that and
> the fix should be in the usual places soon.
I see you fix in the qemu-xen-unstable tree. I think it's a better fix.

Thanks,
 -- Dexuan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.