Bug 175786 - does not respond to SIGHUP signal until next command run
does not respond to SIGHUP signal until next command run
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: bash (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Tim Waugh
Ben Levenson
:
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2005-12-14 17:53 EST by Jason Vas Dias
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 3.0-41
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-15 08:14:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jason Vas Dias 2005-12-14 17:53:32 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 

How reproducible:
100%

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. 

Additional Information:

At first I thought this was an xterm problem, but running eg.
  $ SHELL=ksh xterm
there are no such problems with xterm exiting.
Comment 1 Sammy 2005-12-14 20:49:43 EST
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
boom).

Using ksh like you have does not have the problem. I hope there is a resolution
soon.
Thanks
Comment 3 Tim Waugh 2005-12-15 08:14:53 EST
Thanks for the report.  Should be fixed in bash-3.0-41 in tomorrow's rawhide (or
check out and build current CVS).
Comment 4 Jason Vas Dias 2005-12-15 11:59:41 EST
Yes, bash-3.0-41 fixes the problem - thanks!

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