Hi David,
Am 08.02.2015 um 21:04 schrieb David T. Lewis:
> This looks like some kind of problem in OSProcess. I am not sure what 
> is wrong, so let me try to explain how it works. In Unix, a zombie 
> process is a process that has exited, but its parent process has not 
> yet acknowledged that it has exited. When you run a command with 
> OSProcess, it starts a new process that is a child of the VM process. 
> When that external process exits, it is the responsibility of 
> OSProcess (running in the VM process) to notice this, and to 
> acknowledge the exit by calling the Unix waitpid() system call. When 
> things are working right, you should be able to open a process browser 
> in Squeak, and see an active process labeled "the child OSProcess 
> watcher". 

I see that process while producing Zombies

> That process is normally blocking on a Semaphore, and it wake up 
> whenever the semaphore is signalled (which occurs when the OSProcess 
> plugin detects a SIGCHLD signal from the operating system). Each time 
> it wakes up, it calls a primitive 
> (UnixOSProcessPlugin>>primitiveReapChildProcess). That primitive uses 
> a call to waitpid() to obtain the exit status of the child process, 
> and as soon as that happens the process is no longer in a zombie 
> state. I am not sure where this is going wrong, but one thing you can 
> try is to restart the child watcher process, and see if that makes the 
> zombies go away: "OSProcess accessor restartChildWatcherProcess" 
leaves the number of Zombies constant and continues to produce new ones 
on each call of ExternalUnixOSProcess>>command

> The actual child watcher process is 
> UnixOSProcessAccessor>>grimReaperProcess, so you may want to look at that 

That looked like more than I can handle before I'm off again so I tried 
something different. On Saturday I had bookmarked:
http://en.wikipedia.org/wiki/Zombie_process
where the fourth paragraph of the overview section talks about sending 
SIGCHLD so I tried that.
It works but only adds to the mystery.

For each event in the real world (me moving in front of a PIR sensor) I 
send one
PipeableOSProcess command: 'i2cget -y 1 0x20) and two
ExternalUnixOSProcess command: 'i2cset -y 1 0x20', commandByte

This gave me three new Zombies per event. PipeableOSProcess does not 
understand sigchld so I only sent sigchld to the two 
ExternalUnixOSProcess  end expected a reduction to one Zombie per event. 
But no more Zombies are produced. We called that "Fehler unerkannt 
entkommen" (roughly "the error escaped incognito") and I'm very 
interested what happened here.

> and see if it gives you any other ideas. Please let us know if you 
> figure out the problem. Whatever is going wrong here, I definitely 
> want to get it fixed. Thanks, Dave


Later I'll try to step through grimReaperProcess to see what I can 
learn. And then I'll also look at the version of OSProcess you recently 
uploaded.
Also the other mystery: When I overflowed the process table I couldn't 
from a terminal do 'ls | grep something' but I could do that via 
ExternalUnixOSProcess  without creating additional Zombies. So which 
commands create Zombies and which don't?

Cheers,

Herbert