<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>11254</bug_id>
          
          <creation_ts>2017-03-27 14:30:10 +0000</creation_ts>
          <short_desc>runqemu tap cleanup broken when interrupted</short_desc>
          <delta_ts>2018-10-12 16:38:40 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>Scripts and Tools</component>
          <version>2.3</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>OBSOLETE</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium+</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>2.4 M4</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Jussi Kukkonen">jku</reporter>
          <assigned_to name="Robert Yang">liezhi.yang</assigned_to>
          <cc>mark.hatle</cc>
    
    <cc>randy.macleod</cc>
    
    <cc>ross.burton</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>Regression (Used to work)</cf_regression_type>
          
          <cf_docchange>No (bug/feature does not impact docs)</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>71745</commentid>
    <comment_count>0</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-03-27 14:30:10 +0000</bug_when>
    <thetext>If I let runqemu create it&apos;s own tap interface and never interrupt it, it works fine.

If I interrupt runqemu with ctrl-C, then the tap interface is left there (but without ip). Further runs of runqemu will reuse the tap but will not set the ip address and in fact will remove it on shutdown even if I manually add an ip to the interface. 

Here&apos;s an example of
 * runqemu qemux86
 * ctrl-c
 * runqemu qemux86
In the end the interface does not have IP address.


jku@theory:~/src/poky/build$ runqemu qemux86
runqemu - INFO - Assuming MACHINE = qemux86
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - MACHINE: qemux86
runqemu - INFO - DEPLOY_DIR_IMAGE: /mnt/extra-ssd/tmp/deploy/images/qemux86
runqemu - INFO - Running ls -t /mnt/extra-ssd/tmp/deploy/images/qemux86/*.qemuboot.conf...
runqemu - INFO - CONFFILE: /mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.qemuboot.conf
runqemu - INFO - Continuing with the following parameters:

KERNEL: [/mnt/extra-ssd/tmp/deploy/images/qemux86/bzImage--4.10.2+git0+69bfa87234_827a1164b1-r0-qemux86-20170327113404.bin]
MACHINE: [qemux86]
FSTYPE: [ext4]
ROOTFS: [/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.rootfs.ext4]
CONFFILE: [/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.qemuboot.conf]

runqemu - INFO - Running /bin/ip link...
runqemu - INFO - Found /tmp/qemu-tap-locks/tap0.skip, skipping tap0
runqemu - INFO - Found /tmp/qemu-tap-locks/tap1.skip, skipping tap1
runqemu - INFO - Found /tmp/qemu-tap-locks/tap2.skip, skipping tap2
runqemu - INFO - Found /tmp/qemu-tap-locks/tap3.skip, skipping tap3
runqemu - INFO - Setting up tap interface under sudo
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap4.lock...
runqemu - INFO - Created tap: tap4
runqemu - INFO - Network configuration: 192.168.7.10::192.168.7.9:255.255.255.0
runqemu - INFO - Running ldd /mnt/extra-ssd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-i386...
runqemu - INFO - Running /mnt/extra-ssd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:0a -netdev tap,id=net0,ifname=tap4,script=no,downscript=no -drive file=/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci   -cpu qemu32 -m 256 -serial mon:vc -serial null -kernel /mnt/extra-ssd/tmp/deploy/images/qemux86/bzImage--4.10.2+git0+69bfa87234_827a1164b1-r0-qemux86-20170327113404.bin -append &apos;root=/dev/vda rw highres=off  mem=256M ip=192.168.7.10::192.168.7.9:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 &apos;
^Crunqemu - INFO - Running sudo /home/jku/src/poky/scripts/runqemu-ifdown tap4 /mnt/extra-ssd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native
TUNSETIFF: Device or resource busy
runqemu - INFO - Releasing lockfile for tap device &apos;tap4&apos;
Traceback (most recent call last):
  File &quot;/home/jku/src/poky/scripts/runqemu&quot;, line 1199, in &lt;module&gt;
    ret = main()
  File &quot;/home/jku/src/poky/scripts/runqemu&quot;, line 1192, in main
    config.start_qemu()
  File &quot;/home/jku/src/poky/scripts/runqemu&quot;, line 1123, in start_qemu
    if subprocess.call(cmd, shell=True) != 0:
  File &quot;/usr/lib/python3.4/subprocess.py&quot;, line 539, in call
    return p.wait(timeout=timeout)
  File &quot;/usr/lib/python3.4/subprocess.py&quot;, line 1566, in wait
    (pid, sts) = self._try_wait(0)
  File &quot;/usr/lib/python3.4/subprocess.py&quot;, line 1514, in _try_wait
    (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
  File &quot;/usr/lib/python3.4/subprocess.py&quot;, line 491, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
jku@theory:~/src/poky/build$ qemu-system-i386: terminating on signal 2
^C
jku@theory:~/src/poky/build$ runqemu qemux86
runqemu - INFO - Assuming MACHINE = qemux86
runqemu - INFO - Running MACHINE=qemux86 bitbake -e...
runqemu - INFO - MACHINE: qemux86
runqemu - INFO - DEPLOY_DIR_IMAGE: /mnt/extra-ssd/tmp/deploy/images/qemux86
runqemu - INFO - Running ls -t /mnt/extra-ssd/tmp/deploy/images/qemux86/*.qemuboot.conf...
runqemu - INFO - CONFFILE: /mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.qemuboot.conf
runqemu - INFO - Continuing with the following parameters:

KERNEL: [/mnt/extra-ssd/tmp/deploy/images/qemux86/bzImage--4.10.2+git0+69bfa87234_827a1164b1-r0-qemux86-20170327113404.bin]
MACHINE: [qemux86]
FSTYPE: [ext4]
ROOTFS: [/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.rootfs.ext4]
CONFFILE: [/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.qemuboot.conf]

runqemu - INFO - Running /bin/ip link...
runqemu - INFO - Found /tmp/qemu-tap-locks/tap0.skip, skipping tap0
runqemu - INFO - Found /tmp/qemu-tap-locks/tap1.skip, skipping tap1
runqemu - INFO - Found /tmp/qemu-tap-locks/tap2.skip, skipping tap2
runqemu - INFO - Found /tmp/qemu-tap-locks/tap3.skip, skipping tap3
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap4.lock...
runqemu - INFO - Using preconfigured tap device tap4
runqemu - INFO - If this is not intended, touch /tmp/qemu-tap-locks/tap4.skip to make runqemu skip tap4.
runqemu - INFO - Network configuration: 192.168.7.10::192.168.7.9:255.255.255.0
runqemu - INFO - Running ldd /mnt/extra-ssd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-i386...
runqemu - INFO - Running /mnt/extra-ssd/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot-native/usr/bin/qemu-system-i386 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:0a -netdev tap,id=net0,ifname=tap4,script=no,downscript=no -drive file=/mnt/extra-ssd/tmp/deploy/images/qemux86/core-image-minimal-qemux86-20170327134906.rootfs.ext4,if=virtio,format=raw -vga vmware -show-cursor -usb -usbdevice tablet -device virtio-rng-pci   -cpu qemu32 -m 256 -serial mon:vc -serial null -kernel /mnt/extra-ssd/tmp/deploy/images/qemux86/bzImage--4.10.2+git0+69bfa87234_827a1164b1-r0-qemux86-20170327113404.bin -append &apos;root=/dev/vda rw highres=off  mem=256M ip=192.168.7.10::192.168.7.9:255.255.255.0 vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1 &apos;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>71746</commentid>
    <comment_count>1</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-03-27 14:51:41 +0000</bug_when>
    <thetext>This is especially nasty because the oe-selftest sends SIGTERM to runqemu and that has the same result: in a test like runtime-test.Postinst.test_postinst_rootfs_and_boot only the first of six qemu tests succeeds because on the five subsequent ones there&apos;s no ip on the tap interface.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>71797</commentid>
    <comment_count>2</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-03-28 08:01:38 +0000</bug_when>
    <thetext>I don&apos;t know which component to blame so I&apos;m documenting the oe-selftest things here as well:

qemurunner.py says this after :
&gt; Sending SIGTERM to runqemu

Here runqemu does not run BaseConfig.cleanup() as one would expect, so &quot;tunctl -d tapN&quot; is never executed.



Has this ever worked? Am I doing something wrong?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>71943</commentid>
    <comment_count>3</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-03-31 09:03:06 +0000</bug_when>
    <thetext>&gt; TUNSETIFF: Device or resource busy

This is the issue, I think. &quot;tunctl -d tapN&quot; returns EBUSY (or at least the ioctl does). 

I&apos;ll experiment with retrying tunctl but the real solution would probably be that qemurunner/runqemu copes with this situation...</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>71962</commentid>
    <comment_count>4</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-03-31 12:51:12 +0000</bug_when>
    <thetext>Retrying &quot;tunctl -d&quot; on failure does make this work when using runqemu from shell.

It does nothing to fix the qemurunner case because, as far as I can tell, runqemu is killed before it gets to do &quot;tunctl -d&quot; -- and something still removes the address from the interface.

In case it was not clear the same problem happens when using pregenerated interfaces: when runqemu is killed, something removes the address from the interface.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>72123</commentid>
    <comment_count>5</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2017-04-06 03:29:57 +0000</bug_when>
    <thetext>The tag creating is very fast, I tried several times to interrupt it during creating tap, but failed, Jussi Kukkonen, do you have any updates, please ?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>72124</commentid>
    <comment_count>6</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-04-06 07:42:40 +0000</bug_when>
    <thetext>There is nothing that needs quick reactions in my case:
 * &quot;runqemu &lt;machine&gt;&quot;, let the image boot if you want
 * ctrl-c runqemu

After this there are two bugs as I understand it:
 1. the tap interface still exists even though it was created by runqemu (it should be removed but cleanup never run in this case)
 2. the tap interface loses the ip address very soon after ctrl-c

As a result next runqemu invocation will use an interface that already exists but has no IP address.

Bug #1 is probably there for everyone and has always been: it just hasn&apos;t been very exposed until #2... Bug #2 is something I think didn&apos;t use to happen for me -- I have no idea if it&apos;s a yocto issue or maybe something specific to build host setup (Debian Unstable).</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>74987</commentid>
    <comment_count>7</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2017-07-13 03:07:34 +0000</bug_when>
    <thetext>Hi Jussi,

Would you please try again ? The Ctrl-C doesn&apos;t  break Qemu in my testing.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>74992</commentid>
    <comment_count>8</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2017-07-13 06:37:14 +0000</bug_when>
    <thetext>(In reply to comment #7)
&gt; Hi Jussi,
&gt; 
&gt; Would you please try again ? The Ctrl-C doesn&apos;t  break Qemu in my testing.

It might not happen 100% every time, but yeah, still reproduces.

Are you saying that after &apos;ctrl-C&apos; in runqemu, the tap interface created by runqemu gets properly removed for you?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>76494</commentid>
    <comment_count>9</comment_count>
    <who name="Robert Yang">liezhi.yang</who>
    <bug_when>2017-09-04 09:35:42 +0000</bug_when>
    <thetext>(In reply to comment #8)
&gt; (In reply to comment #7)
&gt; &gt; Hi Jussi,
&gt; &gt; 
&gt; &gt; Would you please try again ? The Ctrl-C doesn&apos;t  break Qemu in my testing.
&gt; 
&gt; It might not happen 100% every time, but yeah, still reproduces.
&gt; 
&gt; Are you saying that after &apos;ctrl-C&apos; in runqemu, the tap interface created by
&gt; runqemu gets properly removed for you?

Yes, it did. I will close the bug, and please reopen it if you can reproduce it again.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>