[Bug 1166419] New: cannot run qemu in timeout
http://bugzilla.suse.com/show_bug.cgi?id=1166419 Bug ID: 1166419 Summary: cannot run qemu in timeout Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs@suse.de Reporter: msuchanek@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- res="$(timeout 30 qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /srv/build/x86_64_ref/arch/x86/boot/bzImage -append console=ttyS0\ panic=-1 | tail -n 1)" ; echo "$res" produces: nothing expected: a kernel panic message -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Virtualization:Other |Virtualization:Other Version|Current |Leap 15.1 Product|openSUSE Tumbleweed |openSUSE Distribution -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 http://bugzilla.suse.com/show_bug.cgi?id=1166419#c1 --- Comment #1 from Michal Suchanek <msuchanek@suse.com> --- Tried to do some regression testing broken: 9284f5825c8646e4a2dd5374dc4eff41fffead57 d5b3467f83afd1866eb096a40d752458a6bb2c64 716e7f283a168a68074bb368cd6e2e078d73de13 d4e3168010d69f5e9ec6a99b1bbcc5ab49d59ac7 ad28e35679f7e3eb31be0308c9d950e96cf2a9cb 1af4c28a3859194396ceabaa173e857692b6eb6a working: 2fe3c88b0cc27c1cac384bb909f75d9593cb9784 025ab3f4109566652b828524a81edbca1f5724ee -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 http://bugzilla.suse.com/show_bug.cgi?id=1166419#c2 --- Comment #2 from Michal Suchanek <msuchanek@suse.com> --- duh, wrong bug -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|virt-bugs@suse.de |brogers@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 http://bugzilla.suse.com/show_bug.cgi?id=1166419#c3 Bruce Rogers <brogers@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msuchanek@suse.com Flags| |needinfo?(msuchanek@suse.co | |m) --- Comment #3 from Bruce Rogers <brogers@suse.com> --- ok - by "wrong bug", I guess you mean just the git commit investigation. This sounds more like a report of an issue of unexpected behavior or interction between shell execution (btw what shell?), and with the timeout command. I'm no expert in either. But if you feel that qemu-system-x86_64 is specifically misbehaving in a way that it should not, could you do some more investigations to prove your point? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166419 http://bugzilla.suse.com/show_bug.cgi?id=1166419#c4 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(msuchanek@suse.co | |m) | --- Comment #4 from Michal Suchanek <msuchanek@suse.com> --- shell is bash. not sure if timeout is builtin. The thing is that qemu tries to do something 'clever' here. If you do qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /srv/build/x86_64_ref/arch/x86/boot/bzImage -append console=ttyS0\ panic=-1 it fucks up your terminal if you do qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /srv/build/x86_64_ref/arch/x86/boot/bzImage -append console=ttyS0\ panic=-1 >boot.log 2>&1 < /dev/null & you know the PID of qemu and can kill it but it fucks up your terminal if you do res="$(qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /srv/build/x86_64_ref/arch/x86/boot/bzImage -append console=ttyS0\ panic=-1 | tail -n 1)" ; echo "$res" your terminal is not fucked up but you don't know the PID of qemu and if it locks up it never ends if you do res="$(timeout 30 qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /srv/build/x86_64_ref/arch/x86/boot/bzImage -append console=ttyS0\ panic=-1 | tail -n 1)" ; echo "$res" you get no output -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 Bruce Rogers <brogers@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|brogers@suse.com |jose.ziviani@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 https://bugzilla.suse.com/show_bug.cgi?id=1166419#c5 Jos� Ricardo Ziviani <jose.ziviani@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Jos� Ricardo Ziviani <jose.ziviani@suse.com> --- You can redirect QEMU serial device to anywhere, including a file and then read the file, for instance: % qemu-system-x86_64 -cpu core2duo -serial file:/tmp/out.txt -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1 && tail /tmp/out.txt || echo "ops..." QEMU 6.0.0 monitor - type 'help' for more information (qemu) [ 2.229946] Call Trace: [ 2.231133] dump_stack+0x76/0x94 [ 2.231400] panic+0x101/0x2e3 [ 2.231549] mount_block_root+0x299/0x313 [ 2.231780] prepare_namespace+0x136/0x165 [ 2.231966] kernel_init_freeable+0x227/0x24b [ 2.232147] ? rest_init+0xb4/0xb4 [ 2.232294] kernel_init+0xa/0x10c [ 2.232436] ret_from_fork+0x22/0x30 [ 2.233467] Kernel Offset: 0x3000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) If the VM doesn't respond for any reason you still have the monitor, which you can user to manipulate the VM, for instance: % qemu-system-x86_64 -cpu core2duo -serial file:/tmp/out.txt -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1 -S && tail /tmp/out.txt || echo "ops..." QEMU 6.0.0 monitor - type 'help' for more information (qemu) info status VM status: paused (prelaunch) (qemu) quit And then you still can redirect the QEMU monitor to a pty or a socket and communicate with it through QMP commands. References: https://qemu-project.gitlab.io/qemu/system/invocation.html https://qemu-project.gitlab.io/qemu/system/monitor.html https://doc.opensuse.org/documentation/leap/virtualization/html/book-virt/ch... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 https://bugzilla.suse.com/show_bug.cgi?id=1166419#c6 Michal Suchanek <msuchanek@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #6 from Michal Suchanek <msuchanek@suse.com> --- It still does not change the fact that qemu cannot be used with the timeout command. Sure, workarounds do exist. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 https://bugzilla.suse.com/show_bug.cgi?id=1166419#c7 Jos� Ricardo Ziviani <jose.ziviani@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Jos� Ricardo Ziviani <jose.ziviani@suse.com> --- (In reply to Michal Suchanek from comment #6)
It still does not change the fact that qemu cannot be used with the timeout command. Sure, workarounds do exist.
Yes, it can: % timeout 15 qemu-system-x86_64 -cpu core2duo -serial file:/tmp/out.txt -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1; tail /tmp/out.txt QEMU 6.0.0 monitor - type 'help' for more information (qemu) [ 2.223459] Call Trace: [ 2.224655] dump_stack+0x76/0x94 [ 2.224903] panic+0x101/0x2e3 [ 2.225050] mount_block_root+0x299/0x313 [ 2.225275] prepare_namespace+0x136/0x165 [ 2.225455] kernel_init_freeable+0x227/0x24b [ 2.225632] ? rest_init+0xb4/0xb4 [ 2.225768] kernel_init+0xa/0x10c [ 2.225902] ret_from_fork+0x22/0x30 [ 2.226865] Kernel Offset: 0x25a00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) % timeout 2 qemu-system-x86_64 -cpu core2duo -serial file:/tmp/out.txt -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1; tail /tmp/out.txt QEMU 6.0.0 monitor - type 'help' for more information (qemu) qemu-system-x86_64: terminating on signal 15 from pid 16851 (timeout) [ 1.156527] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window] [ 1.156781] pci_bus 0000:00: resource 7 [mem 0x40000000-0xfebfffff window] [ 1.157038] pci_bus 0000:00: resource 8 [mem 0x100000000-0x17fffffff window] [ 1.157921] pci 0000:00:01.0: PIIX3: Enabling Passive Release [ 1.158271] pci 0000:00:00.0: Limiting direct PCI/PCI transfers [ 1.158555] pci 0000:00:01.0: Activating ISA DMA hang workarounds [ 1.159023] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff] [ 1.159459] PCI: CLS 0 bytes, default 64 [ 1.164080] check: Scanning for low memory corruption every 60 seconds [ 1.168011] Initialise system trusted keyrings It's a more difficult to control than other commands and script needs some tweak to work properly, for sure. But I don't think there's much more we can do here. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 https://bugzilla.suse.com/show_bug.cgi?id=1166419#c8 --- Comment #8 from Michal Suchanek <msuchanek@suse.com> --- Really nothing can be done? Why is it possible to capture output of any program other than qemu? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1166419 https://bugzilla.suse.com/show_bug.cgi?id=1166419#c9 --- Comment #9 from Jos� Ricardo Ziviani <jose.ziviani@suse.com> --- (In reply to Michal Suchanek from comment #8)
Really nothing can be done?
Why is it possible to capture output of any program other than qemu?
It's not the QEMU output you're really seeing there. It's the kernel sending outputs to a serial device that QEMU emulates and, together with its own output + QEMU monitor, multiplexes everything to the standard output by default. Input is the same story. But the problem here is not to capture the output, but a mismatch between signals. If you try to run the "timeout 30 qemu-system-x86_64" in a subshell, QEMU will not even start and will get killed after 30s. Reading the "timeout" manpage, I found the option --foreground: --foreground when not running timeout directly from a shell prompt, allow COMMAND to read from the TTY and get TTY signals; in this mode, children of COMMAND will not be timed out Your script seems to work as you want with this option: % re=$(timeout --foreground 15 qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1 | tail -n 1); echo $re [ 2.060932] Kernel Offset: 0x5c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) % re=$(timeout --foreground 2 qemu-system-x86_64 -cpu core2duo -smp cores=2,threads=2,sockets=2 -m 1024 -nographic -no-reboot -kernel /boot/vmlinuz -append console=ttyS0\ panic=-1 | tail -n 1); echo $re qemu-system-x86_64: terminating on signal 15 from pid 19000 (timeout) [ 1.082808] clocksource: Switched to clocksource tsc-early -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com