Bug 149325 - set -m hangs in non-interactive session
Summary: set -m hangs in non-interactive session
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pdksh
Version: 4.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Karsten Hopp
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 156322
TreeView+ depends on / blocked
 
Reported: 2005-02-22 14:29 UTC by Paul Stroud
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version: RHBA-2005-538
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-05 14:35:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
First of two test scripts (34 bytes, text/plain)
2005-02-25 17:59 UTC, Paul Stroud
no flags Details
Second of two test scripts (36 bytes, text/plain)
2005-02-25 18:01 UTC, Paul Stroud
no flags Details
This is the patch we put into jobs.c (1.03 KB, patch)
2005-02-25 18:04 UTC, Paul Stroud
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:538 0 qe-ready SHIPPED_LIVE pdksh bug fix update 2005-10-05 04:00:00 UTC

Description Paul Stroud 2005-02-22 14:29:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
FYI I work for IBM and we have been shipping a fixed version of pdksh
with one of our products. One of our customers wanted to get this fix
over to the guys at SuSE so we provided it to them. I wanted to
provide it to you guys(as well as Debian) so that we could get it
fixed in the major distributions as it appears it is no longer being
maintained.

---------------------------------------------------------------------
The gist of the problem was that the shell was waiting for tty input
in a non-interactive script. The result was that the shell would hang
waiting for input that was never coming. I remember writing an example
that ran fine on other ksh's, but failed on pdksh. Sent the example to
the maintainer of pdksh and he suggested the fix that I put in. If I
remember right, it was basically adding a check for if it was an
interactive shell or not. This got us past the problem and was
supposed to end up in the official pdksh. That was a number of years
ago and still no sign of the fix : (
---------------------------------------------------------------------
--- jobs.c      2001-10-27 15:31:57.000000000 -0400
+++ /home/possum/pdksh-5.2.14/jobs.c    1999-07-13 12:50:56.000000000
-0400
@@ -334,17 +334,12 @@
        int i;

        if (Flag(FMONITOR)) {
-               int use_tty;
-               if (Flag(FTALKING)) {
-                       /* Don't call get_tty() 'til we own the tty
process     group */
-                       use_tty = 1;
-                       tty_init(FALSE);
-               } else
-                       use_tty = 0;
+               /* Don't call get_tty() 'til we own the tty process
group */
+               tty_init(FALSE);

 # ifdef TTY_PGRP
                /* no controlling tty, no SIGT* */
-               ttypgrp_ok = use_tty && tty_fd >= 0 && tty_devtty;
+               ttypgrp_ok = tty_fd >= 0 && tty_devtty;

                if (ttypgrp_ok && (our_pgrp = getpgID()) < 0) {
                        warningf(FALSE, "j_init: getpgrp() failed: %s",
@@ -400,10 +395,8 @@
                                        strerror(errno));
                }
 #  endif /* NTTYDISC && TIOCSETD */
-               if (Flag(FTALKING)) {
-                       if (!ttypgrp_ok)
-                               warningf(FALSE, "warning: won't have
full job   control");
-               }
+               if (!ttypgrp_ok)
+                       warningf(FALSE, "warning: won't have full job
control");
 # endif /* TTY_PGRP */
                if (tty_fd >= 0)
                        get_tty(tty_fd, &tty_state);



Version-Release number of selected component (if applicable):
any pdksh

How reproducible:
Always

Steps to Reproduce:
Here is the reproducable error:

two scripts:

::::::::::::::
test1.ksh
::::::::::::::
#!/bin/ksh

./test2.ksh&


::::::::::::::
test2.ksh
::::::::::::::
#!/bin/ksh

set -m
xclock &

exit 1

chmod both scripts +x
NOTE: Make sure you have your DISPLAY variable properly set.
Run: ./test1.ksh &

Actual Results:  You should get a "Stopped" message(you may have to
hit enter to see it), the xclock command should  not run and both
scripts should be left running(you will need to kill them).

A couple of things to note at this point:
1) if you kill test1.ksh, test2.ksh will immediately start hogging the cpu
2) test2.ksh will become parented by init(1) (it was originally
parented by pidof(test1.ksh))

Once you kill test2.ksh everything should return to normal.


Expected Results:  On a normally(properly) working ksh, the scripts
should both finish and only the xclock should be left running. This is
the response I got from Solaris, AIX and the fixed pdksh that we ship.

Additional info:

Please feel free to contact me for any additional information
pstroud


Here is the patch we put into place:

--- jobs.c      2001-10-27 15:31:57.000000000 -0400
+++ /home/possum/pdksh-5.2.14/jobs.c    1999-07-13 12:50:56.000000000
-0400
@@ -334,17 +334,12 @@
        int i;

        if (Flag(FMONITOR)) {
-               int use_tty;
-               if (Flag(FTALKING)) {
-                       /* Don't call get_tty() 'til we own the tty
process     group */
-                       use_tty = 1;
-                       tty_init(FALSE);
-               } else
-                       use_tty = 0;
+               /* Don't call get_tty() 'til we own the tty process
group */
+               tty_init(FALSE);

 # ifdef TTY_PGRP
                /* no controlling tty, no SIGT* */
-               ttypgrp_ok = use_tty && tty_fd >= 0 && tty_devtty;
+               ttypgrp_ok = tty_fd >= 0 && tty_devtty;

                if (ttypgrp_ok && (our_pgrp = getpgID()) < 0) {
                        warningf(FALSE, "j_init: getpgrp() failed: %s",
@@ -400,10 +395,8 @@
                                        strerror(errno));
                }
 #  endif /* NTTYDISC && TIOCSETD */
-               if (Flag(FTALKING)) {
-                       if (!ttypgrp_ok)
-                               warningf(FALSE, "warning: won't have
full job   control");
-               }
+               if (!ttypgrp_ok)
+                       warningf(FALSE, "warning: won't have full job
control");
 # endif /* TTY_PGRP */
                if (tty_fd >= 0)
                        get_tty(tty_fd, &tty_state);

Comment 1 Suzanne Hillman 2005-02-23 20:05:42 UTC
Could you please attach the patch as an attachment, and not inline?

Same for the programs you included for testing purposes?

Comment 4 Paul Stroud 2005-02-25 17:59:28 UTC
Created attachment 111431 [details]
First of two test scripts

Comment 5 Paul Stroud 2005-02-25 18:01:27 UTC
Created attachment 111432 [details]
Second of two test scripts

this script is called from the first script

Comment 6 Paul Stroud 2005-02-25 18:04:03 UTC
Created attachment 111433 [details]
This is the patch we put into jobs.c

This patch will apply to the pdksh from 

ftp://ftp.cs.mun.ca/pub/pdksh/pdksh-5.2.14.tar.gz

Comment 7 Paul Stroud 2005-02-25 18:05:42 UTC
Forgive me for being a moron, first time with Bugzilla;-( Thx for your patience

Comment 8 Suzanne Hillman 2005-02-25 18:46:46 UTC
Thank you! No worries, as far as learning Bugzilla.

Comment 14 Suzanne Hillman 2005-03-16 15:25:59 UTC
Done.

Comment 21 Red Hat Bugzilla 2005-10-05 14:35:52 UTC
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-2005-538.html



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