Ticket #8235 (closed defect: fixed)
2 new bugs in "vboxmanage guestcontrol execute": --verbose and --wait-for exit(stdout,stderr) => Fixed in SVN
Reported by: | Paolo Virtual | Owned by: | pentagonik |
---|---|---|---|
Component: | guest control | Version: | VirtualBox 4.0.2 |
Keywords: | Cc: | ||
Guest type: | Linux | Host type: | other |
Description (last modified by frank) (diff)
After updating to 4.0.2, we encountered two bugs when starting an application via "vboxmanage guestcontrol execute":
1) when adding the paramter --verbose, the Exit Code of the started app is not printed, thus we cannot find out, what the exit code of the started app was
2) when adding --wait-for exit, the system stalls, i.e., the process never returns:
Process '/bin/pidof' (PID: 2067) started
Waiting for process to exit ...
The same happens with stdout and stderr.
Attachments
Change History
comment:1 Changed 12 years ago by pentagonik
- Owner set to pentagonik
- Status changed from new to assigned
- Summary changed from 2 new bugs in "vboxmanage guestcontrol execute": --verbose and --wait-for exit(stdout,stderr) to 2 new bugs in "vboxmanage guestcontrol execute": --verbose and --wait-for exit(stdout,stderr) => Fixed in SVN
comment:2 Changed 12 years ago by Paolo Virtual
Thanks, works in the SVN version. Is there already a release date for the next version?
comment:4 Changed 12 years ago by frank
- Status changed from assigned to closed
- Resolution set to fixed
comment:5 Changed 11 years ago by Nox Metus
- Status changed from closed to reopened
- Resolution fixed deleted
I still experience this bug in 4.1.2 (4.1.2-73507~Ubuntu~natty). I have Ubuntu x64 11.04 host and Windows 7 x64 Professional guest. Sometimes guestcontrol execute works, but most of the times it just waits forever. For example:
$ sudo -Hu builder vboxmanage guestcontrol Win7x64Build execute "c:\windows\system32\where.exe" --username "build" --password "secretpassword" --wait-stdout --verbose -- where Waiting for guest to start process ... Process 'c:\windows\system32\where.exe' (PID: 2792) started Waiting for process to exit ... C:\Windows\System32\where.exe
After printing the last line vboxmanage never returns. The log file just indicates:
00:01:29.510 Executing guest process "c:\windows\system32\where.exe" as user "build" ... 00:01:29.620 Guest process (PID 2792) started
The process PID 2792 exited long ago, but vboxmanage seems doesn't notice.
comment:7 Changed 10 years ago by frank
- Status changed from reopened to closed
- Resolution set to fixed
- Description modified (diff)
Please reopen if still relevant with VBox 4.2.6.
comment:8 Changed 10 years ago by Miebster
- Status changed from closed to reopened
- Resolution fixed deleted
I am experiencing this bug with version 4.2.16 r86992. I have Ubuntu x32 12.04 host and Xubuntu 13.04 x32 guest. Sometimes the guestcontrol execute works, but other times it just waits forever.
This is the vboxmanage command that hangs:
/usr/lib/virtualbox/VBoxManage guestcontrol vat_tst_harvest_2013-08-02-09-58-15 execute --image /usr/bin/python --username *** --password *** --environment SQ_HOST=desktop DISPLAY=:0 CAN_DIR=/home/vat/bundle/CANSimulator SQ_PARENT=ide GPS_DIR=/home/vat/bundle/GpsSimulator SQ_CAN_PORT=4328 SQ_AUT=display-venom-host SQ_SCRIPT_DIR=/home/vat/bundle/UiTest/squish/shared/scripts SQ_CAN_TRAFFIC_PORT=6576 SQ_PRODUCT=venom LD_LIBRARY_PATH=/home/vat/vatmount/qt-4.8.4-Ubuntu12.04/lib SQUISH_USER_SETTINGS_DIR=/home/vat/bundle/UiTest/squish/.squish SQUISH_SCRIPT_DIR=/home/vat/bundle/UiTest/squish/shared/scripts SQ_GPS_PORT=4329 PYTHONPATH=/home/vat/bundle/UiTest/squish/shared/scripts SQ_DISPLAY_IP=127.0.0.1 HOME=/home/vat SQ_DIR=/home/vat/bundle/UiTest/squish SQ_QVFB=1 VENOM_DIR=/home/vat/bundle SQ_HOST_PORT=4322 --timeout 3600000 --verbose --wait-stdout --wait-stderr -- /home/vat/bundle/UiTest/squish/shared/scripts/vat/vat_local tst_harvest
The process running in the VM exited cleanly, but vboxmanage is still waiting for it.
comment:10 Changed 9 years ago by frank
- Status changed from reopened to closed
- Resolution set to fixed
Please reopen if still relevant with VBox 4.3.10.
Thanks for the report; this should be fixed already in SVN and a bugfix will be available in the next upcoming version of VBox.