<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="Verdana">A great big thanks.<br>
<br>
As many guests as I open and close daily it was getting rather
annoying. I usually have two that stay running 24/7 but to clear
the zombies I had to save them and shut the manager down.<br>
<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 06/04/2013 09:58 AM, Klaus Espenlaub
wrote:<br>
</div>
<blockquote cite="mid:51AE00AC.6060304@oracle.com" type="cite">Hi
Perry,
<br>
<br>
On 04.06.2013 14:23, Perry Halbert wrote:
<br>
<blockquote type="cite">Good day Klaus,
<br>
<br>
Strange indeed. As I said I didn't notice this before but can't
promise
<br>
exactly when It started. I don't usually need to trace why
excessive
<br>
idle CPU ticks are present. I did check the released (4.2.12)
and it
<br>
does not produce this behavior.
<br>
</blockquote>
<br>
Not strange any more after finding the cause, as usual. This was a
very well hidden regression which sneaked in when adding the
default VM frontend setting in trunk (which included simplifying
the frontend handling). It resulted in an empty string being
stored in the session type, which means "we didn't start this
client process", suppressing the process reaping. Now it's clear
why it only happened for GUI VMs and not headless ones...
<br>
<br>
<blockquote type="cite">I do have backups of my builds and can if
needed to see where it
<br>
started. (at least to the middle of March)
<br>
</blockquote>
<br>
No need, was easy enough to find.
<br>
<br>
Will be in the repository soon...
<br>
<br>
Klaus
<br>
<br>
<blockquote type="cite">Question if I may, what is the purpose of
the %U in the startup command
<br>
(VirtualBox %U)
<br>
<br>
<br>
Perry
<br>
<br>
<br>
On 06/04/2013 04:06 AM, Klaus Espenlaub wrote:
<br>
<blockquote type="cite">Hi Perry,
<br>
<br>
On 03.06.2013 23:10, Perry Halbert wrote:
<br>
<blockquote type="cite">More research on this shows that using
VBoxHeadless -s <guest> or shift
<br>
start from the main manager does not produce the zombies.
<br>
<br>
Only normal starting from the main manager or shortcut does.
<br>
</blockquote>
Very very strange, I'm not aware of any intentional code
changes in this
<br>
area for approx. a year, and actually I have no idea why
VBoxHeadless
<br>
processes would consistently behave differently. The
distinction should
<br>
be "VM started through the API" (i.e. anything in the GUI, and
<br>
VBoxManage startvm) or "VM started directly" (i.e.
<br>
VirtualBox/VBoxHeadless/VBoxSDL --startvm foo). In the latter
case
<br>
VBoxSVC is not the parent and thus isn't responsible for
waiting for the
<br>
process exit result.
<br>
<br>
I can reproduce, so will investigate what's causing this
behavior change.
<br>
<br>
Thanks for letting us know...
<br>
<br>
Klaus
<br>
<br>
<blockquote type="cite">On 06/01/2013 11:56 AM, Perry Halbert
wrote:
<br>
<blockquote type="cite">Strange behavior the last few weeks.
<br>
<br>
Stopping ( even saved state ) a guest leaves a zombie
process on the
<br>
host.
<br>
Each new start and it uses a new pid and the zombie is
still there.
<br>
Stop all guests and the main manager and all processes
including the
<br>
zombie processes finally clear.
<br>
<br>
Host = Ubuntu 12.04 LTS guest = any.
<br>
<br>
USER PID %CPU %MEM VSZ RSS TTY STAT
START TIME COMMAND
<br>
perry 9538 6.0 0.0 0 0 ? Z
11:36 0:34
<br>
[VirtualBox] <defunct>
<br>
perry 9934 4.3 0.0 0 0 ? Z
11:37 0:22
<br>
[VirtualBox] <defunct>
<br>
<br>
Normally I would not have seen this but the processor was
doing work
<br>
when it should have been idle. I have never seen a zombie
process
<br>
using CPU ticks before. Wait long enough and the %CPU
will finally
<br>
get to zero but it seems to take like 20 to 30 minutes to
do so.
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>