1

I have a strange situation.

I have a c-written program “A” which takes as argument the name of other executables, e.g. “B”, “C”, “D” etc.. The main job of “A” is to fork and start “B”, “C” etc, then check if they crash, and in that case restart the crashed process.

Also, process “A” runs a separated thread for RTC sync purposes. “A” is started as /bin/sh -c A B C D etc.

I am on an embedded environment and I am using a customized kernel derived from Linux 4.4.57.

Now to the the problem: it happens sometimes my process “A” becomes zombie!

Some observations I made:

  • the parent process /bin/sh -c, which started “A” is still alive;
  • none of the child processes “B”, “C”, etc. are dead;
  • “A” responds to signals;
  • if I kill the parent process /bin/sh -c, “A”'s parent becomes init (1) but still, the process remains zombie;
  • the only way to kill the zombie “A” is to issue a kill -9 «pid-of-A»;
  • the RTC sync thread is still running!;

Now, because of “A” responding to signals and the internal thread still running, this zombie process is driving me crazy.

What explains such behavior? Might it be something related to kernel build configuration?

EDIT: I have looked better at the code and found out that “A” is started as a daemon with the following command: start-stop-daemon -b --start --quiet --pidfile /var/run/A.pid --background --exec /bin/sh -- -c "A B C D > /var/log/log 2>&1"

UPDATE: I've been able to replicate the same exact behavior by calling pthread_exit(). The problem is that I can't find any reference to phread_exit on the original source. Is there any other way the main thread might stop leaving alive all the others?

  • How do you know that it is a zombie? How did you check? And what did the system tell you? – JdeBP Nov 20 '18 at 12:02
  • Doing ps shows the process name in brackets, and also top lists the process as Z – alain Nov 20 '18 at 12:04
1

A zombie process is a process that has completed, but still has an entry in the process table, because for example its children are still alive (see Wikipedia).

So if, as you say, none of B, C and D is dead, and A finishes execution, it will become a zombie until all of B, C and D also finish execution.

This is normal behaviour.

So this looks like a bug in A: It shouldn't die while its children are still alive, because it's supposed to monitor the children. Fix the bug in A, and don't worry about it becoming a zombie.

  • What about the fact that A still responds to signals and also its internal RTC thread is still running? Anyway, your answer explains why even killing the parent /bin/bash process does not reap the zombie. – alain Nov 20 '18 at 9:04
  • Signals are caught by registering a handler; nothing says this function can't be active after it has called exit. Same for other threads. The real question is what action A has done to tell the OS that it has finished, when in fact it hasn't. Did you attach a debugger (e.g. gdb) before it became a zombie? Possibly the debugger will catch this action. – dirkt Nov 20 '18 at 12:46
1

If you're using pthread_exit() in the main() function, this SO post suggests that the main thread could enter a zombie state, but other threads continue running. Since calling pthread_exit() in main() is perfectly legal, I suppose this is a normal state of affairs and this particular undead being is harmless. You can ignore it, or wait for other threads in main() instead of using pthread_exit() there.

  • I've checked and I am not using pthread_exit in process A (and its subthread). – alain Nov 20 '18 at 9:25
  • Then I suppose we're left guessing as to what you're actually doing in your code. – muru Nov 20 '18 at 9:26
  • Actually, I am trying to replicate the behavior on a minimum working example. I'll let you know. – alain Nov 20 '18 at 9:28
0

I found the problem and the solution of my problem by looking at dmesg: I found out there was a "Internal error: Oops: 817 [#1] ARM" caused by a custom kernel function in a proc file. The proc file was read by the main thread of the process becoming zombie, and sometimes this operation caused the main thread to die... This is exactly similar to the answer by @muru. I fixed the funciton and now the process does not die anymore. Thanks anyway to everybody.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.