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?

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

3 Answers 3

Reset to default
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.

Improve this answer
2
  • 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, 2018 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, 2018 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.

Improve this answer
3
  • I've checked and I am not using pthread_exit in process A (and its subthread).
    – alain
    Nov 20, 2018 at 9:25
  • Then I suppose we're left guessing as to what you're actually doing in your code.
    – muru
    Nov 20, 2018 at 9:26
  • Actually, I am trying to replicate the behavior on a minimum working example. I'll let you know.
    – alain
    Nov 20, 2018 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .