Jerry Feldman wrote : | On Mon, 28 Apr 2003 12:54:27 -0700 | | dries wrote: | > Hello List readers, | > ......... snip | > /* | > * Make very sure it has ended and get return value | > */ | > kill(prog->pid,SIGKILL); | > waitpid(prog->pid,&status,WUNTRACED); // | WNOHANG); | > ... snip| | I generally use wait(2) rather than waitpid, although waitpid(2) should | be working. Did you check the return value from waitpid? It should | return either the pid of the process killed or -1. | Another way to handle this is to use a SIGCHILD signal handler. Well, that's what i'm doing now, i use the signal(SIGCHLD,SIG_IGN); to prevent zombies, this works but i think there is something weird going on with the waitpid thing since it should work (from what i read in the documentation of both kill and wait/waitpid). I can not reallly use the wait(&status) routine since i want to wait for a specific process and leave others untouched. (the program can have more than one external processes running). Well, anyhow, the signal(SIGCHLD,SIG_IGN); seems to work, at this point that is good enough for me !. Grtz and thanx Dries Pruimboom -- <End of message>

On Tue, 29 Apr 2003 14:18:25 -0400 (PYT) Raúl Gutiérrez Segalés wrote:

Excuse my ignorance, but you cant mix signal(for SIGCHLD) and waitpid right? Sure you can. If you have a signal handler, the child generates a signal to the parent. If you issue a waitpid(2), it should fail if that child is no longer running.

-- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Thu, 01 May 2003 08:25:52 -0700 dries wrote:

es that's correct, this doesn't explain however why a kill-waitpid sequence fials ! does it.

It strikes me as a bit odd (to say the least) that the kill-waitpid sequence doesn't work, the man pages give no clue why this would result in a zombie. That is true. Both kill(2) and waitpid(2) are system calls. For some reason, you hit a bug in the kernel, or the child might have been doing something, like trying to take input from the terminal.

If you have a small test program that exhibits this problem, could you send it to me. When things should work, but do not, there is generally something else involved. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Thu, 01 May 2003 15:38:48 -0700 dries wrote:

Jerry Feldman wrote :

| If you have a small test program that exhibits this problem, could you| send it to me. When things should work, but do not, there is generally| something else involved.

Well, that's part of the problem, i can't get this faulty situation to occur on my own machine, i can only get it to appear on a slower (300 Mhz) PC. I think the problem has got something to do with task-swaps and timing since on the slower PC it happens regularly but not 100% of the time. Since the PC is slower it spends more time in the kill-waitpid sequence (these commands are right behind one another in my source), thus giving a higher change that a taskswap is performed in this timeframe. Beware that i am just guessing here !.

But to shortly answer your question, no, i haven't been able to make a program that shows this behaviour on my PC. sorry about that. (the same program that fails on the slower machine passes on a faster machine.

What is notable is that the waitpid is passed, it returns immediately so waitpid sees that the process is ended. Still a zombie appears.

So, you are saying that waitpid returns -1. Does the zombie remain until you log out?, or does it eventually terminate itself? Possibly it is waiting on a page fault or there was a missed signal. I would still add a signal handler on SIGCHILD in the parent. For the handler, simply put in a simple wait(2): void HandleSigchild(int sig) { pid_t rv; if (sig == SIGCHILD) { rv = wait(NULL); } } It won't hurt to add this. I normally use sigaction(2) to set up the signal handlers, but you can also use the older signal(2) system call also. -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9