Bug 474056 - shell don't execute trap if executing inotifywait
shell don't execute trap if executing inotifywait
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Roman Rakus
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-01 16:42 EST by Patrice Dumas
Modified: 2014-01-12 19:08 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-02 10:04:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Patrice Dumas 2008-12-01 16:42:31 EST
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):


How reproducible:


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>
Actual results:

No aaa appears in the first terminal.

Expected results:

aaa should be echoed on the first terminal.

Additional info:
Comment 1 Patrice Dumas 2008-12-01 16:47:51 EST
A strace leads to:

waitpid(-1, 0xbfe99898, 0)              = ? ERESTARTSYS (To be restarted)
--- SIGTERM (Terminated) @ 0 (0) ---
sigreturn()                             = ? (mask now [CHLD])

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 [])
Comment 2 Roman Rakus 2008-12-02 10:04:32 EST
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
Comment 3 Patrice Dumas 2008-12-02 10:18:41 EST
Sorry for the bogus report...

Note You need to log in before you can comment on or make changes to this bug.