Bug 175786 - does not respond to SIGHUP signal until next command run
Summary: does not respond to SIGHUP signal until next command run
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: bash
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
 
Reported: 2005-12-14 22:53 UTC by Jason Vas Dias
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 3.0-41
Clone Of:
Environment:
Last Closed: 2005-12-15 13:14:53 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jason Vas Dias 2005-12-14 22:53:32 UTC
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-15 01:49:43 UTC
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 13:14:53 UTC
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 16:59:41 UTC
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.