Status: New
Owner: ----

New issue 1117 by [email protected]: (patch) GlusterFS 3.6 breaks qemu start -> enhance RunCmd utility
https://code.google.com/p/ganeti/issues/detail?id=1117

What software version are you running? Please provide the output of "gnt-
cluster --version", "gnt-cluster version", and "hspace --version".
gnt-cluster (ganeti v2.11.6) 2.11.6

What distribution are you using?
Ubuntu 14.04

What steps will reproduce the problem?
1. Have a cluster with qemu and disks in GlusterFS
2. Upgrade GlusterFS to 3.6
3. VMs won't start at all

What is the expected output? What do you see instead?
VM should start instead of gnt-instance timeouting

Please provide any additional information below.

I've dug quite deeply into the issue. The problem is that the qemu command launched by noded never returns. RunCmd is called, outputs the command to the log but never ends, although the -daemonize option is given on the qemu command line. After a lot of prospection, I've found that glusterfs calls a dup(2) somewhere for its own usage. As such, the FD of the pipe that is set by ganeti's popen call is not closed at all (it's transmitted to the child), even after qemu forks itself for daemonization. This leads the polling of FDs (process.py, _RunCmdPipe), used for reading the command output to never finish, since the FD is still open but no data will come and nothing will close it (the pipe is hold by the daemonized qemu).

It's not obvious at first but this demonstrates that relying on the FDs being closed to say that a child terminated is too simple. We have to check if it is really gone or not. In this case the child is in fact a zombie since ganeti never wait()'ed for it: ganeti is stuck polling FDs, which do not belong anymore to the direct child it started but to a daemonization sub-child.

Attached is a small patch that checks for child's life each time before attempting a new poll on the FDs. This solves the problem for me. It would maybe be better to set a default timeout when polling the FDs since a racecond may occur if the child dies between the check and the polling. Since I'm no ganeti dev I've no idea if this is a good idea, but setting pt=10000 or something like that would probably be better (makes the loop always run every 10s, even if no event was caught on the FDs).



Attachments:
        patch-ganeti-qemu-fds.diff  407 bytes

--
You received this message because this project is configured to send all issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

Reply via email to