When my child process crash, it need a lot of time to do coredump (because I dump hugepages) and then the parent got SIGCHLD, but it is too late for me. So I use signal handler in child process to notify parent process and then do coredump, I just want to send the child pid to parent process. But I am not sure which mechanism is safe in this case. pipe or ipc message queue or unix socket?
You haven't provided enough details, but I assume in almost all the languages that allow you to explicitly spawn a new process there is a mechanism to get the child PID right when it gets created.
For example in C when you call fork() if the child process is created successfully it returns the child PID.
Yeah, I choose POSIX message queue finally, though it may be unsafe to call mq_send() in signal handler.
Related
When calling fork() the PID of the parent is saved in the child's PCB. In which case would it be useful for the child to know its parent's PID?
A process may wish to know if it was started by the init process at system startup, for example, and modify its behaviour accordingly.
Or, it may wish to communicate with its parent, say, to indicate something is complete, by sending a signal.
I need to watch for a process with a known PID in Linux. Once it is terminated want to execute a command with reason of termination.
Questions
How to subscribe to process health rather than polling (e.g. watch
command)?
Where to inject the event handler in OS' user space?
How to detect the termination/failure reason inside handler?
Note
The process I intend to keep a tab on is not forked as a child process of some parent through which it can be monitored.
The process type is generic (good number of them are daemons)
The only way to get that kind of control over another process, is to use ptrace(2) to trace the target process. You would use ptrace(PTRACE_ATTACH, pid) to attach to the process, after which you effectively become the target process's parent (and can use wait or more ptrace calls to figure out what the process is doing).
I am reading several shell implementations. One thing that confuses me is it seems very common to block SIGCHLD before spawning a child process and unblock it right after fork() in both parent and child processes.
What is the purpose of doing that? What will happen if I don't block this signal?
So bascially, it is used to avoid the race between parent and child. This can make sure the sigchild handler won't be received before parent executing something.
In linux, after calling fork(), my child process is going to call exec soon. Is there a way for the parent process to wait() and not do anything till the child has exec'ed?
Thanks.
There is no (API) way for the parent to know that the child is performing an exec().
But there is a nice pipe-trick: have the child inherit a filedescriptor (for a pipe) and (before the fork() ) set the close-on-exec flag for the pipe. The parent will be notified by an EOF on the pipe when it is closed by the exec().
Please note that this does not need any collaboration from the child.
Use vfork() instead of fork(). That causes the parent to be suspended until the child either exits or calls one of the execve() family of functions.
You need to use waitpid using the process ID returned from the fork call that is returned to the parent.
EDIT
Or if you mean that you want to know that the child is about to call exec use pause in the parent. Get the child to call kill with a suitable signal to the parent (whose process ID can be obtained from getppid). USR1 signal might be useful to use. Do this just before the exec.
There is a function in QNX procmgr_guardian which sets a child process as the guardian of the other child process in case of the parent's death.
Is there such functionality in Linux too ? How do I implement it in Linux? Any pointers are appreciated.
There is no direct method for monitoring a process that is not your own child. However, there is a hack you can use: Create a FIFO using pipe(); ensure that the process to be monitored holds the write end of the pipe (and that it is closed in all other processes). If the process dies, an EOF condition will be signalled in the read end of the pipe (ie, select will indicate a readable condition).
If you want the process to be reparented when its immediate parent dies, you may be able to achieve this with PID namespaces. By arranging for the 'guardian' process to be PID 1 in the PID namespace, it will inherit all orphaned processes in that namespace.