Red Hat Bugzilla – Bug 892996
qemu-ga leaks fds to exec()ed processes [TestOnly]
Last modified: 2013-11-21 01:28:01 EST
Description of problem: qemu-ga doesn't open the pid file with the O_CLOEXEC flag set, which causes it to be leaked when executing new processes. As far as I could check, this only happens with the pid file but it's worth it to double check all opened files. Version-Release number of selected component (if applicable): qemu-kvm-0.12.1.2-2.348.el6 How reproducible: To reproduce the problem I've replaced /sbin/shutdown by a script that writes its pid to a file in tmp, then I executed the guest-shutdown command and checked the /proc/<pid>/fd entry: lrwx------. 1 root root 64 Jan 8 10:08 0 -> /dev/null lrwx------. 1 root root 64 Jan 8 10:08 1 -> /dev/null lrwx------. 1 root root 64 Jan 8 10:08 2 -> /dev/null lr-x------. 1 root root 64 Jan 8 10:08 255 -> /sbin/shutdown l-wx------. 1 root root 64 Jan 8 10:08 3 -> /usr/local/var/run/qemu-ga.pid
It seems that the log file fd is also leaked.
Patches posted upstream: http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg01190.html
This bug should be solved by pre-requisite bug 952873, setting TestOnly in Keywords and Summary.
Reproduce this issue on qemu-kvm-0.12.1.2-2.365.el6.x86_64. host info: kernel-2.6.32-376.el6.x86_64 qemu-kvm-0.12.1.2-2.365.el6.x86_64 guest info: kernel-2.6.32-376.el6.x86_64 qemu-guest-agent-0.12.1.2-2.365.el6.x86_64 Steps: 1.start guest with virtio serial. # /usr/libexec/qemu-kvm -M rhel6.4.0 ... -chardev socket,path=/tmp/qga.sock,server,nowait,id=qga0 -device virtio-serial -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 2.move /sbin/shutdown to /sbin/shutdown.old. 3.create a /sbin/shutdown script containing: #!/bin/bash echo $$ > /tmp/my-pid sleep 1h 4.start guest agent inside guest and connect the chardev socket in host side for sending commands to guest: # nc -U /tmp/qga.sock readline 5.issue guest-shutdown to qemu-ga. {"execute":"guest-shutdown","arguments":{"mode":"powerdown"}} 6.get the shutdown process pid from /tmp/my-pid. # cat /tmp/my-pid 6002 7.check the /proc/<pid>/fd dir, it shouldn't contain qemu-ga.pid # ls -l /proc/6002/fd total 0 lrwx------. 1 root root 64 May 8 06:53 0 -> /dev/null lrwx------. 1 root root 64 May 8 06:53 1 -> /dev/null lrwx------. 1 root root 64 May 8 06:53 2 -> /dev/null lr-x------. 1 root root 64 May 8 06:53 255 -> /sbin/shutdown Resutls: after step 7, the log file fd was also leaked. Make qa_ack+.
Tried the qemu-kvm-0.12.1.2-2.366.el6.x86_64, but check the /proc/<pid>/fd dir that did not contain qemu-ga.pid. Host info: kernel-2.6.32-376.el6.x86_64 qemu-kvm-0.12.1.2-2.366.el6.x86_64 Guest info: kernel-2.6.32-376.el6.x86_64 qemu-guest-agent-0.12.1.2-2.366.el6.x86_64 Steps: the same to comment #7. Results: check the /proc/<pid>/fd dir, but it did not contain qemu-ga.pid, the log file fd was also leaked. I tested many times for this qemu version, all of them failed. # nc -U /tmp/qga.sock readline {"execute":"guest-ping"} {"return": {}} {"execute":"guest-shutdown","arguments":{"mode":"powerdown"}} # cat /tmp/my-pid 6070 # ls -l /proc/6070/fd total 0 lrwx------. 1 root root 64 May 8 06:58 0 -> /dev/null lrwx------. 1 root root 64 May 8 06:58 1 -> /dev/null lrwx------. 1 root root 64 May 8 06:58 2 -> /dev/null lr-x------. 1 root root 64 May 8 06:58 255 -> /sbin/shutdown Luiz Capitulino, could you help check it, does it not fix correctly or miss the code in the patch? Should we need to RE-ASSIGNED it ? Best Regards. sluo
(In reply to comment #8) > Luiz Capitulino, could you help check it, does it not fix correctly or miss > the code in the patch? Should we need to RE-ASSIGNED it ? > Ignore this conclusion please. it's right that the /proc/<pid>/fd did not contain qemu-ga.pid. >7.check the /proc/<pid>/fd dir, it shouldn't contain qemu-ga.pid BTW, why i cann't reproduce it ? I also tried the qemu-kvm-0.12.1.2-2.360.el6.x86_64 and qemu-guest-agent-0.12.1.2-2.360.el6.x86_64, it also did not contail the qemu-ga.pid. Host info: kernel-2.6.32-376.el6.x86_64 qemu-kvm-0.12.1.2-2.360.el6.x86_64 guest info: kernel-2.6.32-376.el6.x86_64 qemu-guest-agent-0.12.1.2-2.360.el6.x86_64 # cat /tmp/my-pid 6043 # ls -l /proc/6043/fd total 0 lrwx------. 1 root root 64 May 8 07:39 0 -> /dev/null lrwx------. 1 root root 64 May 8 07:39 1 -> /dev/null lrwx------. 1 root root 64 May 8 07:39 2 -> /dev/null lr-x------. 1 root root 64 May 8 07:39 255 -> /sbin/shutdown
I also tried qemu-kvm-0.12.1.2-2.348.el6, it is the same, it also did not contail the qemu-ga.pid. # cat /tmp/my-pid 6057 # ls -l /proc/6057/fd total 0 lrwx------. 1 root root 64 May 8 10:48 0 -> /dev/null lrwx------. 1 root root 64 May 8 10:48 1 -> /dev/null lrwx------. 1 root root 64 May 8 10:48 2 -> /dev/null lr-x------. 1 root root 64 May 8 10:48 255 -> /sbin/shutdown If i use the upstream qemu(QEMU 1.4.50) and just use the official guest agent(qemu-guest-agent-0.12.1.2-2.348.el6.x86_64), it is the same, it also did not contail the qemu-ga.pid. # cat /tmp/my-pid 5988 # ls -l /proc/5988/fd total 0 lrwx------. 1 root root 64 May 8 11:00 0 -> /dev/null lrwx------. 1 root root 64 May 8 11:00 1 -> /dev/null lrwx------. 1 root root 64 May 8 11:00 2 -> /dev/null lr-x------. 1 root root 64 May 8 11:00 255 -> /sbin/shutdown
Hello Sibiao, did you start qemu-ga in daemon mode (with the "service" command for example, or with the --daemonize command line option)? It only creates a pid file if you start it in daemon mode. Also, please don't use the -363, -364, -365 builds for testing. Compare -362 against -366. Thanks!
(In reply to comment #11) > Hello Sibiao, > > did you start qemu-ga in daemon mode (with the "service" command for > example, or with the --daemonize command line option)? It only creates a pid > file if you start it in daemon mode. > > Also, please don't use the -363, -364, -365 builds for testing. Compare -362 > against -366. Thanks! Thanks for your kindly helps. hmm...I just started the qemu-ga service in guest(qemu-ga on) during my past testing. I re-tested it as your indication that start qemu-ga in daemon mode(qemu-ga on --daemonize) with the same steps as comment #7, the testing results as following. - Reproduce: host info: kernel-2.6.32-376.el6.x86_64 qemu-kvm-0.12.1.2-2.362.el6.x86_64 guest info: kernel-2.6.32-376.el6.x86_64 qemu-guest-agent-0.12.1.2-2.362.el6.x86_64 guest]# qemu-ga on --daemonize guest]# ps axu | grep qemu-ga root 6171 0.0 0.0 7144 632 ? Ss 13:36 0:00 qemu-ga on --daemonize root 6173 0.0 0.0 103236 872 pts/1 S+ 13:36 0:00 grep qemu-ga guest]# service qemu-ga status qemu-ga (pid 6171) is running... host]# nc -U /tmp/qga.sock readline {"execute":"guest-ping"} {"return": {}} {"execute":"guest-shutdown","arguments":{"mode":"powerdown"}} guest]# cat /tmp/my-pid 6186 guest]# ls -l /proc/6186/fd total 0 lrwx------. 1 root root 64 May 8 13:37 0 -> /dev/null lrwx------. 1 root root 64 May 8 13:37 1 -> /dev/null lrwx------. 1 root root 64 May 8 13:37 2 -> /dev/null lr-x------. 1 root root 64 May 8 13:37 255 -> /sbin/shutdown l-wx------. 1 root root 64 May 8 13:37 3 -> /var/run/qemu-ga.pid - Verification: host info: kernel-2.6.32-376.el6.x86_64 qemu-kvm-0.12.1.2-2.366.el6.x86_64 guest info: kernel-2.6.32-376.el6.x86_64 qemu-guest-agent-0.12.1.2-2.366.el6.x86_64 guest]# ps axu | grep qemu-ga root 6012 0.0 0.0 103236 872 pts/1 S+ 13:41 0:00 grep qemu-ga guest]# qemu-ga on --daemonize guest]# ps axu | grep qemu-ga root 6014 0.0 0.0 7180 884 ? Ss 13:41 0:00 qemu-ga on --daemonize root 6016 0.0 0.0 103236 864 pts/1 R+ 13:41 0:00 grep qemu-ga guest]# service qemu-ga status qemu-ga (pid 6014) is running... host]# nc -U /tmp/qga.sock readline {"execute":"guest-ping"} {"return": {}} {"execute":"guest-shutdown","arguments":{"mode":"powerdown"}} guest]# cat /tmp/my-pid 6035 guest]# ls -l /proc/6035/fd total 0 lrwx------. 1 root root 64 May 8 13:43 0 -> /dev/null lrwx------. 1 root root 64 May 8 13:43 1 -> /dev/null lrwx------. 1 root root 64 May 8 13:43 2 -> /dev/null lr-x------. 1 root root 64 May 8 13:43 255 -> /sbin/shutdown Base on above, this issue has been fixed correctly.
Setting to VERIFIED according to comment 12.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1553.html