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.
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.
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 $!
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.
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.)
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.
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.
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.
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
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.
*** Bug 240822 has been marked as a duplicate of this bug. ***