notification of core generation by child to parent

[utsav]

When will the parent know that the child has crashed. Is it after the generation of the core file or as soon as the core generation starts.
Also if the parrent is notified after the core is generated is there a mechanism via which the parent can become aware of the start of core generation immediately.

[Gordon Morrison]

I don't think a crashing process will ever notify its parent of anything, but eventually it will time out and the parent will assume it has died. This is how zombie (defunct) processes occur: a child takes too long to come back with its result, so the parent assumes its dead and ignores it, so the child just sits there, sulking.

[utsav]

Hi Gordan,
Thanks for the reply. Let me explain you the problem in some detail.
The parent process does a waitpid . So the parent will know when the child ends. Now here is the problem. I want to perform certain operations in the parent as soon as the child crashes or starts to generate core. If the child takes too long to generate a core file the parent process is not able to act as long as the file is being generated as only after the generation of the core the waitpid gets un-blocked.

There has to be some mechanism via which the parent or for that matter some other process can come to know of the core generation.

[Gordon Morrison]

It's many years since I was a developer, so I don't think I can be much further help. All I can think of is to check the exit status of the child process, but that will still probably wait until the dore dump is finished. If you don't particularly want the core file, you can block it from being created by creating a directory called "core" in the location where your application wants to write its own core file. That would at least speed up the child's exit.

[A. Clay Stephenson]

You have an interesting approach to fixing a problem. It would make far more sense to find the problem in the child process but to avoid the core dump caused by the default signal handler's invocation of the abort() function, you need to install a custom signal handler to override the default action. The wait() will not be satified until the process terminates and it doesn't terminate until abort() finishes.

[Gordon Morrison]

> You have an interesting approach to fixing a problem.
Gee, thanks (I think:o)
I agree that the solution is to fix the crashing process, but as I said, I haven't written anything that needs compiling for ages, so custom signal handlers are no longer in my repertoire. (And the question was about the parent dealing with the crash of the child.)
The defence rests, M'lud.

[Stephen Keane]

There may be a way to do what you want to do. The problem with the situation you describe is that the child can only communicate with the parent via the child's exit() call. Thus the parent must wait for the child to exit before it can determine the status of the child. The child won't exit until it has finished its core dump.

Some ways around the problem are:

(a) Stop the child from core dumping, so it will exit immediately (as suggested in posts above).

(b) Provide the child with another mechanism to communicate with its parent.

The ideal sitiation would be that the child doesn't core dump in the first place! If you wish to see the core dumps (for debugging purposes) then that leaves option (b). Unfortunately (b) would require some code changes in both the parent and the child.

The mechanisms you can explore for communicating between the child and the parent are:

(1) The child traps signals (see sigaction(2)) that would lead to a core dump (see signal(5) for signals who's default effect is (ii) - i.e. core dump). These would be SIGABRT, SIGFPE, SIGTRAP, SIGQUIT etc).

(2) The child then either:

(a) sends a signal (see kill(2)) to the parent (which means the child needs to know its parent PID - not too difficult to determine, see getppid(2)). The parent traps the signal and now knows that the child is core-dumping. The parent does whatever it wants with the information.

(b) The child raises a semaphore to indicate that it is about to core dump. The parent will see the semaphore raised and do whatever it wants with the information.

(3) The child then continues with the default action for the signal, i.e. core dumps.

It depends on where you want to go and whether you have access to the child code I suppose?

[rick jones]

the overhead is possibly excessive, but I wonder what the parent could divine from using ttrace(2) against the child. not sure what could be done, but it seemed interesting on the surface.

btw, just what sort of things do you want to try to do before/while the child process is dumping core?

[utsav]

Stephen thanks for the reply. I am trying certain things on those lines. lets see how far it goes and how it behaves.
Thanks for the comments. What we are trying is a kind of failover mechanism and trying to restore the client with the previous state when it crashes. The parent process is effectively a daemon here that keeps track of the child, which is the actual server. I was not in a position to deploy a parallel second child(server) due to some inherent constraints. The child is not stateless and maintains references of the connected clients. If you want to know more details let me know.
Thanks for the replies. Will update you all as soon as I reach the next level.

Thanks

[Stephen Keane]

If you need any help with sigaction(), just post again and I'll see what I can do to help. It's not the most intuitive of system calls :)