Description of problem: This script don't execute the trap when signaled with kill -TERM: echo $$ trap 'echo aaa' TERM inotifywait /etc/yum.conf If inotifywait is replaced by read, everything is right. And if there is no trap, a TERM terminates the script. The culprit may also be inotifywait (or kill?), or it may not be a bug. Version-Release number of selected component (if applicable): bash-3.2-29.fc10.i386 How reproducible: Always. Steps to Reproduce: 1.run the script above in a terminal. The script will echo its <pid>. 2.In another terminal issue a kill -TERM <pid> 3. Actual results: No aaa appears in the first terminal. Expected results: aaa should be echoed on the first terminal. Additional info:
A strace leads to: waitpid(-1, 0xbfe99898, 0) = ? ERESTARTSYS (To be restarted) --- SIGTERM (Terminated) @ 0 (0) --- sigreturn() = ? (mask now [CHLD]) waitpid(-1, With read, it is: read(0, 0x8102c60, 128) = ? ERESTARTSYS (To be restarted) --- SIGTERM (Terminated) @ 0 (0) --- rt_sigprocmask(SIG_BLOCK, [TERM], [TERM], 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [TERM], 8) = 0 write(1, "aaa\n"..., 4aaa ) = 4 rt_sigprocmask(SIG_SETMASK, [TERM], NULL, 8) = 0 sigreturn() = ? (mask now []) read(0,
This is an expected behavior. In bash(1), the last part of section SIGNALS says: " If bash is waiting for a command to complete and receives a signal for which a trap has been set, the trap will not be executed until the command completes. When bash is waiting for an asynchronous command via the wait builtin, the reception of a signal for which a trap has been set will cause the wait builtin to return immediately with an exit status greater than 128, immediately after which the trap is executed. " `read' is a bash builtin, `inotifywait' is a simple command
Sorry for the bogus report...