I found the answer in Managing Signal Handling for daemons that fork() very helpful for what I’m doing. I’m unsure about how to solve
“You will therefore need to install any signal handling in the execed process when it starts up”
I don’t have control over the process that start up. Is there any way for me to force some signal handles on the execed from the parent of the fork?
Edit:{
I’m writing a Perl module that monitors long-running processes. Instead of
system(<long-running cmd>);
you’d use
my_system(<ID>, <long-running cmd>);
I create a lock file for the <ID> and don’t let another my_system(<ID>...) call through if there is one currently running with a matching ID.
The parent fork/execs <long-running cmd> and is in change of cleaning up the lock file when it terminates. I’d like to have the child self-sufficient so the parent can exit (or so the child can take care of itself if the parent gets a kill -9).
}
On Unix systems, you can make an exec’d process ignore signals (unless the process chooses to override what you say), but you can’t force it to set a handler for it. The most you can do is leave the relevant signal being handled by the default handler.
If you think about it, you’ll realize why. To install a signal handler, you have to provide a function pointer – but the process that does the
exec()can’t specify one of its functions because they won’t exist as part of the exec’d process, and it can’t specify one of the exec’d processes functions because they don’t exist as part of the exec’ing process. Similarly, you can’t registeratexit()handlers in the exec’ing process that will be honoured by the exec’d process.As to your programming problem, there’s a good reason that the lock file normally contains the process ID (pid) of the process that holds the lock; it allows you to check whether that process is still around, even if it isn’t your child. You can read the pid from the lock file, and then use
kill(pid, 0)which will tell you if the process exists and you can signal it without actually sending any signal.