S
ske
Guest
1. What is not true? Your example doesn't set any signal up to be ignored. To ignore it, you need to set the action to an empty string. Other actions, like the one in the example, will not be inherited by the child. 2. Specifically SIGUSR1 doesn't seem to do much in the shell when not trapped or ignored, when I test it. So when the sub-shell doesn't react to it, that result is consistent with the signal just having been reset to its original state when the sub-shell was started. (That's all the shell can do when starting another program, since the trap procedure can not be inherited.) Other signals have other defaults or original states. (E.g SIGHUP will kill the sub-shell, even when trapped in the parent, when I try it.) If the sub-shell had stopped reacting to a signal that ordinarily would have killed the shell, then one conclusion might have been that perhaps Progress had changed to signal to be ignored. Or if you try to set a trap procedure in the sub-shell, and that doesn't work (doesn't react to signals sent directly to the sub-shell), then that may be caused by the parent (or earlier) process having set the signal to be ignored before starting the sub-shell. 3. When you start another shell from Progress, that is a another child process, which has no reason to react to any signal sent to the Progress process. So sending signals to Progress, and checking what happens to the sub-shell doesn't say anything about what signal handling Progress is using for itself. I thought you tried to find out how Progress was reacting to the signal? Which process did you send the signal to? 4. When the parent process, e.g sh or Progress, starts a sub-shell, usually they change some of their signal settings for themselves to ignore or wait until the sub-shell returns, in order to protect themselves. This way, for instance, when you press the interrupt or quit key on the keyboard, only the active sub-shell will react to it, not the parent too. (The signal from the keyboard may be sent to all processes running on that terminal.) So even testing how the parent process reacts while waiting for a sub-shell, is not representative of how they react when actually running alone, either. 5. I don't know what Progress sets all the signals to for the sub-shell when starting one. It could set them any way it likes. But Progress can not make the sub-shell inherit any signal handler that Progress is using internally. That wouldn't make sense, either. So how the subshell reacts to them doesn't say much about how the parent Progress reacts. Probably Progress should be restoring the original state of SIGUSR1 from when Progress was started, like the shell. 6. As an interesting variation of your example, you could also have tested a sub-shell started in the background with "&". In that case, the parent shell will not wait until the sub-shell finishes, before it reacts to signals. (The parent will also set the background shell to ignore SIGINT and SIGQUIT, if job control i not used. This is different than for a foreground sub-shell. The rest of the signals should be the same as when the parent shell started, except ignored signals.) This further illustrates that how the parent process reacts while waiting for a foreground sub-shell is not representative of what it might do in other situations, including when running alone with no sub-shells. 7. (An interactive shell shell also by default ignores SIGTERM, SIGQUIT, and catches SIGINT while running. So testing these signals doesn't say anything about how they were set in the parent, and will not reflect how other signals are handled.) Is there anything in this that doesn't seem to fit your results? Maybe I misunderstood your test somehow? To see what signals actually reach Progress, I would still suggest replacing Progress, with a script of your own. Or use some system tool to track signals, like others suggested. I don't see any other way to check what signals are being sent to Progress (except possibly finding out that they are ignored).
Continue reading...
Continue reading...