Bug 200148 - ksh scripts issue TERM signal on certain commands
ksh scripts issue TERM signal on certain commands
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pdksh (Show other bugs)
3.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Karsten Hopp
: Reopened
: 240822 (view as bug list)
Depends On:
Blocks: 190430
  Show dependency treegraph
 
Reported: 2006-07-25 14:42 EDT by jbmorris
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0111
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-25 18:23:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description jbmorris 2006-07-25 14:42:07 EDT
Description of problem:
Following the latest RPM updates on Friday, July 21, we are experiencing TERM 
signals in places where we never did before.  So far we have noticed this with 
the typeset command (using typeset -f on a non-existent function) and with the 
wait command (apparently using wait on a non-existent PID, or a PID not owned 
by the user issuing the command, although full details on when this happens 
and when it doesn't aren't clear).


Version-Release number of selected component (if applicable):
Version     : 5.2.14                            Vendor: Red Hat, Inc.
Release     : 21.5                          Build Date: Fri 19 May 2006 
12:47:33 PM EDT


How reproducible:
For typeset, run this script:
#!/bin/ksh
trap "echo hey" TERM
typeset -f whattheheck

For wait, run this script:
#!/bin/ksh
trap "echo hey" TERM
wait 1


Steps to Reproduce:
1. Create script files with above contents.
2. Run script files.

  
Actual results:
"hey" is printed to sysout in both instances.


Expected results:
Nothing should be printed to sysout because no signal should be issued.


Additional info:
The typeset -f issue seems pretty clear cut, but we're not sure of every 
circumstance that does and doesn't produce a signal from wait.  We also don't 
know if there may be other built-in shell commands which are now unexpectedly 
producing singals.
Comment 1 jbmorris 2006-07-26 18:13:54 EDT
Some additional information...today I caught a signal while exiting from 
Oracle's sqlplus program due to an error.  The return status was 1, which is 
normal for this circumstance, but until the latest RPM update, this sort of 
exit did not cause a TERM signal to be issued.

Since I know we did not change sqlplus, I am now assuming that the programs 
are not generating the signals, but perhaps the shell itself is, or something 
at a lower level.
Comment 2 Karsten Hopp 2006-07-27 07:12:32 EDT
The old pdksh had a bug and didn't recognize signals by name (bug #192137)
The new one has a fix for this and shows the expected behaviour.

the first script (typeset) terminates after an error and the trap handler is run.
The second one terminates as it beleaves that job 1 has already terminated:
wait [job]
 Wait  for  the  specified  job(s) to finish.  The exit status of
 wait is that of the last specified  job:  if  the  last  job  is
 killed  by  a signal, the exit status is 128 + the number of the
 signal (see kill -l exit-status above); if  the  last  specified
 job  can’t  be  found  (because it never existed, or had already
 finished), the exit status of wait  is  127.   See  Job  Control
 below  for  the format of job.  Wait will return if a signal for
 which a trap has been set is received, or if a HUP, INT or  QUIT
 signal is received.

What you probably wanted is the following script:
#!/bin/ksh
trap "echo hey" TERM
sleep 10&
wait $!
Comment 3 jbmorris 2006-07-27 10:20:23 EDT
For the second script, in reality we are using $!, certainly not "wait 1", but 
I was unable to consistently reproduce the problem with $!, so I used the 
example above instead.

I am confused by your response.  So you are saying this is desired behavior 
which was broken in the previous release?  Or do we have the wrong version of 
pdksh after the RPM?

Take for instance this script:
#!/bin/ksh
trap "echo trapped" TERM
typeset -f whattheheck
echo "got to the end"

Prior to the RPM update, this would print only "got to the end", 
not "trapped".  Are you saying it was supposed to have printed "trapped" as 
well but didn't due to the signal names being wrong?  I have tried this script 
on AIX and SunOS and it only prints "got to the end", not "trapped".  So are 
you saying that RedHat Linux is intentionally behaving different, or do we 
somehow have something wrong?

Is typeset -f on a non-existent function supposed to produce a TERM signal?  
If so, why?  I am not used to this behavior on other versions of Unix, nor on 
previous version of Linux.  Or does it only produce a TERM when a trap is 
set?  I notice that if I comment out the trap line, I still get the "got to 
the end" line printed.  Does that mean in that case the typeset -f did NOT 
issue a TERM signal, since the script was not terminated?

What about my sqlplus comment?  Why would that issue a TERM?  Is TERM now 
being issued whenever a program exits with a non-zero return code?  That seems 
unnecessary and undesirable to me.
Comment 4 jbmorris 2006-07-27 10:43:31 EDT
Let me approach this from a different angle.  Consider this script:

#!/bin/ksh
trap "echo trapped" TERM
while ((1==1))
do
  echo happy
  sleep 5
done

Run this script in the background and it will print "happy" to the screen for 
as long as you let it.  Then issue "kill %1" (or whatever its job number is), 
and on our RedHat Linux machine, the script will immediately die.  The 
expected behavior is that the TERM signal will get trapped and "trapped" will 
get written to the screen.  This is the behavior of this script on SunOS and 
AIX.

This must be a bug, since it is not catching signals that it should (clearly), 
but is catching signals that it shouldn't (at least in my opinion).

Or, am I perhaps describing bug #192137 (whose details I cannot see), and 
somehow our RPM update has given us the wrong version of pdksh instead of the 
fixed version?

(NOTE: I tried to re-open this bug, but got this curious message:

You tried to change the Status field from CLOSED to NEW, but only the owner or 
submitter of the bug, or a sufficiently empowered user, may change that field.

I am the person in the Reporter field, so I assume that means I am 
the "submitter", so I don't know why it won't let me re-open it.)
Comment 5 Karsten Hopp 2006-07-27 11:02:31 EDT
I'll take another look at the issue, maby I didn't understand it the first time.

I'll reopen the bugzilla for you so that it doesn't fall off my TODO list.
Comment 6 Karsten Hopp 2006-07-31 09:07:24 EDT
would you mind testing a new package ?
I've uploaded it to http://people.redhat.com/karsten/pdksh-5.2.14-21.7.i386.rpm
and contains a fix for the creation of signal lists.
It also has a totally different (much simpler) memory handling to fix several
segfaults but I expect no surprises by these changes.
Comment 7 jbmorris 2006-08-01 20:54:14 EDT
Our system administrators installed this RPM today, and it was rigorously 
tested here and appears to be working.  Thank you very much for addressing this 
issue so quickly!

I tried to change the status to VERIFIED but it wouldn't let me.
Comment 30 Red Hat Bugzilla 2007-04-18 09:17:45 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0111.html
Comment 33 Suzanne Yeghiayan 2007-04-25 18:23:58 EDT
Unintentional side effect of adding the FasTrack stream. The link will become
live once the package gets rolled up in the forthcoming update, the tooling
writes out its url but until the package gets moved into the update it's dead.
This was the first time we realized that and it's being addressed now. Not sure
what the resolution will be.
Comment 36 Tomas Smetana 2007-06-06 05:33:25 EDT
*** Bug 240822 has been marked as a duplicate of this bug. ***

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