S
ske
Guest
Forcing a sub-process to ignore a signal like that, even if it was a signal that the sub-process would usually set up its own trap for, would work if the sub-process was sh (or a sh script), because sh doesn't allow setting a trap procedure for a signal that was already ignored when sh was started. It would also work if the child process never changed the signal for its own purposes. Then it would just remain ignored from the parent. But not allowing a trap procedure to be set if it was ignored when the process started, is just a rule that sh (most shells) applies for itself (and its scripts). Other commands, like Progress, can change the handling even for a signal that was originally ignored, if they want to. The child process could choose to not change it if it is already ignored, just like sh. But I guess Progress does not choose to do so, and always explicitly sets up a signal handler to produce a protrace file. I haven't seen any way to tell Progress to ignore (or not handle) any signals. But I don't know all about all versions of Progress in all environments. (But I guess, if there was some way, then someone would have said that by now.) I noticed that KB article knowledgebase.progress.com/.../P112486 seems to be under the impression that SIGUSR1 actually could be blocked by being trapped in the script that started Progress. (It is mentioned as a precaution, not something they suggest doing.) I think that is an error. I didn't see that in any other KB article, and you already tried it and it didn't work, and I have tried it too and it didn't work. There are some other KB articles about how Progress reacts to signals, but they don't mention any way to change them: knowledgebase.progress.com/.../P133912 knowledgebase.progress.com/.../P67938
Continue reading...
Continue reading...