IIRC, it was felt that- it would be too complicated and error prone to fully handle SIGINT in the IOC shell and all the routines that it called.
- IOCs should be insulated against an erroneous SIGINT or SIGQUIT from the IOC shell session and from other signals from outside the process.
Perhaps default signal handling should be restored in child processes? But, as Michael points out, you can always SIGKILL a recalcitrant child process if needed. On Jun 19, 2019, at 12:00 PM, Michael Davidsaver via Core-talk < [email protected]> wrote:
On 6/19/19 8:29 AM, Ralph Lange via Core-talk wrote: Question:
It seems (looking at start_routine() in libCom/osi/osd/posix/osdThread.c) that all threads that the IOC starts are blocking all signals.
Is that correct, or am I missing something?
If that's correct, why is it done?
We have a case where a separate process started from an EPICS IOC subordinate (driver) thread - via fork() and execv() calls - seems to be "immune" against all attempts to kill it (except -9 obviously).
Any ideas?
SIGKILL can't be blocked. Maybe a "zombie" process which it's parent isn't wait()ing for it? https://en.wikipedia.org/wiki/Zombie_process
|
