Hi ,
In my program, for a process A executing operation, there are multiple threads created.
One of the thread A checks whether process is active or not
Second thread B executes a function
One of the periodic thread C calls a callback function that executes an audit after every 30 secs.

In the audit , the function uses g_spawn_commmand_line_sync() function to spawn a child process that executes a command line (shell script).

Since g_spawn_commmand_line_sync() spawns a new child process .
In the error case scenario, the spawned child process got stuck and became zombie process. It did not get killed.Also it acquired sockets which were assigned to a thread B executing operation.

Even though the thread B got terminated ,the child process did not release the sockets that were connected to it.


My question is ,I have to automate this in C program that if it finds spawned process of g_spawn_commmand_line_sync() defunct, the
health check thread B should be able to clean it without klling the main process.

i could not find any spawn function that will help me find the PID of g_spawn_commmand_line_sync() spawned process.

I get the details from ps commands. But how can I find it in a c-program?

Zombie processes cannot be "killed" - they are already dead. They also don't usually hang around long as the process that started them is usually waiting for their exit signal. Once the exit signal is handled the zombie process is removed.

One of the instances that can keep a zombie process around (nearly forever) is hardware malfunction. In this case, the (now) zombie process is holding some kernel locks within the device driver, and the device is not signalling completion back to the driver (which would then release the locks, and release the process). One case in software causing this is NFS - if the NFS mount is identified as "hard", then the locks will not be released if the server crashes - until the server comes back, and the timeout recovery can then decide to release the locks. When NFS filesystem is mounted "soft", then local interrupts/aborts/... can interrupt the driver, and force the release of the locks.

The problem you have is that g_spawn_commmand_line_sync() is designed to clean up after the process exits. Since the process hasn't exited, it can't give any pids as they are internal data. If you want the pid, you have to use g_spawn_command_line_async(), and do the waiting for process completion separately.

What needs to be done is the parent of that process needs to deal with it, the main way being paying attention to signals from that process to ensure that closure occurs.

I wrote a blog entry how to do exactly this, and for the same reason, I forked children and didn't wait for their termination signals, then found I grew zombies over time, How to kill those Zombies. Read the section titled "More Complex Case" where it covers architectures that can't afford to wait and stop processing. You can periodically re-check for signals from your children.

Unfortunately even though they are your children, once they become zombies, you have to shoot them in the head.

I would add that providing you end up waiting for a signal from your child processes, what this now means is that you will no longer grow zombies. A child process may temporarily become a zombie, for instance say you only check once per second via a timer expiration, then up to that one second time span you could've had a child process which completed and is a zombie until you the parent processes the exit signal.

Just using SIGCHLD will eliminate the polling.

The thing is, the function being used IS cleaning up when it gets the signal.