On Mit, 2015-01-07 at 14:40 +0530, Yash Jain wrote:
wait and waitpid would not work because a Process A would wait for process B(which is a parent of the daemon), process B immediately exits and process A would be notified. In my case, I want to query the status of process C(which is child of
process B) / grandchild of process A which is a child of init after process B terminates,
And exactly here ends the usual Unix story because when "Process C" is a child of `init` (or whatever process has pid 1), "Process A" shouldn't receive a SIGCLD (because that is delivered only to it's parent process and one of the main purposes of daemonizing "Process C" is to get to into that position;-).
fork fork process A -------------> Process B --------------> Process C
Process A should query the status of process C
Once process C is daemon, Process C would be the the child of init.
Can we do something by making a process A to be a daemon (child of init), because process A and process C are sibling, can siblings query the status of each other.
Not with the usual model as outlined above. The short term solution are - to implement it in the daemons/program/applications. - to start the daemon in some "debug mode" so that it doesn't daemonize itself. - (if you can't that or won't fix the daemon) to hack init so that when some PID terminates, it notifies the other process. There were patches on LKML so that any process can choose to inherit daemonized processes forked by (it's own;-) child processes (instead of 'init' - the main reason being the typical desktop manager (kdn, gdm, xdm, ....) process which also may want to do that) but I don't know the state of them .... [ crap deleted ] Kind regards, Bernd -- "I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong." - Linus Torvalds