Bug 149325 - set -m hangs in non-interactive session
set -m hangs in non-interactive session
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pdksh (Show other bugs)
4.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Karsten Hopp
:
Depends On:
Blocks: 156322
  Show dependency treegraph
 
Reported: 2005-02-22 09:29 EST by Paul Stroud
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHBA-2005-538
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-05 10:35:52 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)
First of two test scripts (34 bytes, text/plain)
2005-02-25 12:59 EST, Paul Stroud
no flags Details
Second of two test scripts (36 bytes, text/plain)
2005-02-25 13:01 EST, Paul Stroud
no flags Details
This is the patch we put into jobs.c (1.03 KB, patch)
2005-02-25 13:04 EST, Paul Stroud
no flags Details | Diff

  None (edit)
Description Paul Stroud 2005-02-22 09:29:46 EST
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@gmail.com


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 15:05:42 EST
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 12:59:28 EST
Created attachment 111431 [details]
First of two test scripts
Comment 5 Paul Stroud 2005-02-25 13:01:27 EST
Created attachment 111432 [details]
Second of two test scripts

this script is called from the first script
Comment 6 Paul Stroud 2005-02-25 13:04:03 EST
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 13:05:42 EST
Forgive me for being a moron, first time with Bugzilla;-( Thx for your patience
Comment 8 Suzanne Hillman 2005-02-25 13:46:46 EST
Thank you! No worries, as far as learning Bugzilla.
Comment 14 Suzanne Hillman 2005-03-16 10:25:59 EST
Done.
Comment 21 Red Hat Bugzilla 2005-10-05 10:35:52 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-2005-538.html

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