Red Hat Bugzilla – Bug 175786
does not respond to SIGHUP signal until next command run
Last modified: 2007-11-30 17:11:19 EST
Description of problem:
This weird problem started happening with 3.0-38 and is still in 3.0-40 :
When sent the SIGHUP signal, bash does not exit until another command is typed
and return is pressed.
This prevents xterm running a bash process from exiting, as it sends its
child bash process a SIGHUP signal, and then waits for the SIGCHLD from
the exited child before exiting .
When the bash child process has been sent a SIGHUP, only when an actual command
is typed and return is pressed does bash actually exit .
Also typing 'kill -HUP $$' in the bash child does make it exit correctly.
Version-Release number of selected component (if applicable):
3.0-38 to 3.0-40.1
Steps to Reproduce:
1. start xterm with your $SHELL set to bash
2. try to click on the X/Exit button of the window manager frame
3. xterm (bash) does not exit
4. Press return - xterm (bash) does not exit
5. type any command or statement - eg. 'ls', 'echo $$' - then press return and
bash & xterm exits.
The same behaviour occurs if the bash child process is set a HUP signal from
the root user, not xterm - it waits for the next command before exiting.
At first I thought this was an xterm problem, but running eg.
$ SHELL=ksh xterm
there are no such problems with xterm exiting.
Wow...I spent hours trying to find the problem with KDE konsole, which does
the same behavior and more (it thinks an application in running even though
non is and when you say close it does not, until you type in a command and
Using ksh like you have does not have the problem. I hope there is a resolution
Thanks for the report. Should be fixed in bash-3.0-41 in tomorrow's rawhide (or
check out and build current CVS).
Yes, bash-3.0-41 fixes the problem - thanks!