0

I came across this SO post:

https://stackoverflow.com/questions/356722/killing-a-defunct-process-on-unix-system

"You have killed the process, but a dead process doesn't disappear from the process table until its parent process performs a task called "reaping" (essentially calling wait(3) for that process to read its exit status). Dead processes that haven't been reaped are called "zombie processes."

Here is my defunct process:

 ps aux | grep ruby
1000     11958 16.3  0.0      0     0 pts/3    Z    Jul11 1065:28 [ruby] <defunct>

This is what it was supposed to do:

RAILS_ENV=production bundle exec ruby lib/daemons/db_service_ctl start% 

Basically it runs the Rails daemons process. I wanted to restart it so I tried to kill it but it refused to die, and now I have a defunct process.

Here is its parent process:

ps -f 11958            
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
1000     11958 11957 16 Jul11 pts/3    Z    1065:28 [ruby] <defunct>

The parent process is 11957. The proc cmdline looks like this:

 /proc/11957 $ cat cmdline
/bin/sh./script/db_service.sh%   

That looks like the same shell script that I executed as the daemons process!

So how can this be the parent process too?

1 Answer 1

0

Simply -- the script db.service.sh that is the parent of your ruby process started an executable (with the PID 11958). When you start a program from a script it is a new process, with the parent being the script that called it. Consider this script:

#!/bin/bash

cat

When you start it as test.sh, you will see that the bash is the parent, and the cat is the child:

xxx   4087 10976  0 08:29 pts/2    00:00:00 /bin/bash ./test.sh
xxx   4088  4087  0 08:29 pts/2    00:00:00 cat

You must log in to answer this question.

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