problem building zsh in background

problem building zsh in background

[Jens Petersen]

Any comments on this bug report:
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102042>?

It seems easy to reproduce with both 4.0.7 and 4.1.1: eg

% rm -rf zsh-4.0.7
% tar tar jxf zsh-4.0.7.tar.bz2
% cd zsh-4.0.7
% ./configure &
:
:
checking if kill(pid, 0) returns ESRCH correctly... yes
checking if POSIX sigsuspend() works... yes
checking if tcsetpgrp() actually works...
[1]  + suspended (tty output)  ./configure


In the above report Roland McGrath comments "The zsh
configure script runs a program that does tcsetpgrp on fd 0
(stdin), which is broken in multiple ways.  If the input
were redirected then the test would give a false negative.
Since the input is your terminal and the job is in the
background, it rightly gets SIGTTOU for trying to perform
tcsetpgrp.  The only way a test of this nature can be safe
is if it's done on a specially created pty, e.g. in the
child of a forkpty call, but using ptys is not fully
portable so zsh is kind of stuck here."

Anyone looked into this before?

Jens

Re: problem building zsh in background

[Philippe Troin]

Jens Petersen <petersen@redhat.com> writes:

> Any comments on this bug report:
> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102042>?
> 
> It seems easy to reproduce with both 4.0.7 and 4.1.1: eg
> 
> % rm -rf zsh-4.0.7
> % tar tar jxf zsh-4.0.7.tar.bz2
> % cd zsh-4.0.7
> % ./configure &
> :
> :
> checking if kill(pid, 0) returns ESRCH correctly... yes
> checking if POSIX sigsuspend() works... yes
> checking if tcsetpgrp() actually works...
> [1]  + suspended (tty output)  ./configure
> 
> 
> In the above report Roland McGrath comments "The zsh
> configure script runs a program that does tcsetpgrp on fd 0
> (stdin), which is broken in multiple ways.  If the input
> were redirected then the test would give a false negative.
> Since the input is your terminal and the job is in the
> background, it rightly gets SIGTTOU for trying to perform
> tcsetpgrp.  The only way a test of this nature can be safe
> is if it's done on a specially created pty, e.g. in the
> child of a forkpty call, but using ptys is not fully
> portable so zsh is kind of stuck here."
> 
> Anyone looked into this before?

We were looking into it on the zsh-workers mailing list yesterday.

Check-out the thread at
http://www.zsh.org/mla/workers/2003/msg00895.html

Phil.

Re: problem building zsh in background

[Jens Petersen]

Thanks for your reply.

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    PT> Jens Petersen <petersen@redhat.com> writes:
    >> Any comments on this bug report:
    >> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102042>?
    >>
    >> It seems easy to reproduce with both 4.0.7 and 4.1.1:
    >> eg
    >>
    >> % rm -rf zsh-4.0.7 tar tar jxf zsh-4.0.7.tar.bz2 cd
    >> % zsh-4.0.7 ./configure &
    >> : : checking if kill(pid, 0) returns ESRCH
    >> correctly... yes checking if POSIX sigsuspend()
    >> works... yes checking if tcsetpgrp() actually
    >> works...  [1] + suspended (tty output) ./configure

    PT> Check-out the thread at
    PT> http://www.zsh.org/mla/workers/2003/msg00895.html

I tried both patches, but I am afraid ./configure still
hangs for me when run in the background.

If you would like to see the strace output or something,
please ask. :)

Jens

Re: problem building zsh in background

[Philippe Troin]

Jens Petersen <petersen@redhat.com> writes:

> Thanks for your reply.
> 
> >>>>> "PT" == Philippe Troin <phil@fifi.org> writes:
> 
>     PT> Jens Petersen <petersen@redhat.com> writes:
>     >> Any comments on this bug report:
>     >> <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=102042>?
>     >>
>     >> It seems easy to reproduce with both 4.0.7 and 4.1.1:
>     >> eg
>     >>
>     >> % rm -rf zsh-4.0.7 tar tar jxf zsh-4.0.7.tar.bz2 cd
>     >> % zsh-4.0.7 ./configure &
>     >> : : checking if kill(pid, 0) returns ESRCH
>     >> correctly... yes checking if POSIX sigsuspend()
>     >> works... yes checking if tcsetpgrp() actually
>     >> works...  [1] + suspended (tty output) ./configure
> 
>     PT> Check-out the thread at
>     PT> http://www.zsh.org/mla/workers/2003/msg00895.html
> 
> I tried both patches, but I am afraid ./configure still
> hangs for me when run in the background.

Mmmh, did you run autoconf between step 1 and step 3? I'm sorry that
my instructions were not clearer.

 1. patch

 2. run: autoconf

 3. run: ./configure
 
> If you would like to see the strace output or something,
> please ask. :)

This is likely to be huge. If you did not forget to run autoconf as I
suspect, then please send me privately the strace output (bzip2'ed).
Strace should be run like this:

  strace -f -o strace.out /bin/sh -x ./configure

Thanks.
Phil.

Re: problem building zsh in background

[Jens Petersen]

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    PT> Jens Petersen <petersen@redhat.com> writes:
    >> >> : : checking if kill(pid, 0) returns ESRCH
    >> >> correctly... yes checking if POSIX sigsuspend()
    >> >> works... yes checking if tcsetpgrp() actually
    >> >> works...  [1] + suspended (tty output) ./configure
    >>
    PT> Check-out the thread at
    PT> http://www.zsh.org/mla/workers/2003/msg00895.html
    >>
    >> I tried both patches, but I am afraid ./configure
    >> still hangs for me when run in the background.

    PT> Mmmh, did you run autoconf between step 1 and step 3?

Doh, you're quite right: I was getting confused by the
autoconf in the makefile, but of course that doesn't happen
until after configure is done...

Thanks for all your help,

Jens

Re: problem building zsh in background

[Jens Petersen]

>>>>> "juhp" == Jens Petersen <petersen@redhat.com> writes:

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    >>> >> works... yes checking if tcsetpgrp() actually
    >>> >> works...  [1] + suspended (tty output)
    >>> >> ./configure
    >>>
    PT> Check-out the thread at
    PT> http://www.zsh.org/mla/workers/2003/msg00895.html

Ok, I have no problems with the first weaker patch, but with
the second patch (msg00896.html) when there is no tty I see:

:
checking if kill(pid, 0) returns ESRCH correctly... yes
checking if POSIX sigsuspend() works... yes
checking if tcsetpgrp() actually works... notty
configure: error: no controlling tty
% 

This can be reproduced easily with zsh and nohup:
a) in new terminal, go to a clean tree and run:

  % nohup ./configure &!
  % Ctrl-d   # (ie close the terminal)

b) Then in another terminal "tail -f" nohup.out...

For now I applied the first patch in zsh-4.0.7-2.

Jens

Re: problem building zsh in background

[Philippe Troin]

Jens Petersen <petersen@redhat.com> writes:

> >>>>> "juhp" == Jens Petersen <petersen@redhat.com> writes:
> 
> >>>>> "PT" == Philippe Troin <phil@fifi.org> writes:
> 
>     >>> >> works... yes checking if tcsetpgrp() actually
>     >>> >> works...  [1] + suspended (tty output)
>     >>> >> ./configure
>     >>>
>     PT> Check-out the thread at
>     PT> http://www.zsh.org/mla/workers/2003/msg00895.html
> 
> Ok, I have no problems with the first weaker patch, but with
> the second patch (msg00896.html) when there is no tty I see:
> 
> :
> checking if kill(pid, 0) returns ESRCH correctly... yes
> checking if POSIX sigsuspend() works... yes
> checking if tcsetpgrp() actually works... notty
> configure: error: no controlling tty
> % 

Yes, I know.

The first patch fails to detect if configure runs without a
controlling tty, does not run the test and assumes that tcsetpgrp()
works correctly.

The second patch aborts the configure run in that case.

The first patch was a work in progress, the second patch is supposed
to be an improvement :-)

Why do you want to run configure with nohup?

I guess I could run the test in a separate, created pty, but that is
going to be messy to do portably in configure.

Phil.

Re: problem building zsh in background

[Danek Duvall]

On Sat, Nov 29, 2003 at 09:43:50PM -0800, Philippe Troin wrote:

> Why do you want to run configure with nohup?

In my case, it's more likely that I'd want to run configure from a cron
script -- nightly builds.

> I guess I could run the test in a separate, created pty, but that is
> going to be messy to do portably in configure.

Maybe a configure flag that forces tcsetpgrp() to be recognized as
working, and skip the test?  I know that it works properly on my
platform, so I could use the flag and not worry about whether the build
will hang or abort because of the test ...

Danek

Re: problem building zsh in background

[Jens Petersen]

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    PT> Jens Petersen <petersen@redhat.com> writes:
    >> but with the second patch (msg00896.html) when there
    >> is no tty I see:
    >>
    >> : checking if kill(pid, 0) returns ESRCH
    >> correctly... yes checking if POSIX sigsuspend()
    >> works... yes checking if tcsetpgrp() actually
    >> works... notty configure: error: no controlling tty

    PT> The first patch fails to detect if configure runs
    PT> without a controlling tty, does not run the test and
    PT> assumes that tcsetpgrp() works correctly.

    PT> The second patch aborts the configure run in that
    PT> case.

Ok. :)

    PT> The first patch was a work in progress, the second
    PT> patch is supposed to be an improvement :-)

    PT> Why do you want to run configure with nohup?

Building with the second patch fails in our buildsystem. ;-)

    PT> I guess I could run the test in a separate, created
    PT> pty, but that is going to be messy to do portably in
    PT> configure.

I don't know which platform this test benefits, but
presumably with modern glibc it works ok.  Perhaps the test
could be skipped except on affected platforms?

Jens

Re: problem building zsh in background

[Geoff Wing]

Danek Duvall <duvall@emufarm.org> typed:
: On Sat, Nov 29, 2003 at 09:43:50PM -0800, Philippe Troin wrote:
:> Why do you want to run configure with nohup?
: In my case, it's more likely that I'd want to run configure from a cron
: script -- nightly builds.

Hmm, you shouldn't need nohup to run from cron.  I've been doing this for
over two years without problems with something like the following script
and have it email the results to me.

#!/bin/sh
cd /my/zsh/path
make realclean || true
CVS_RSH=ssh /usr/bin/cvs update -dP
Util/preconfig
./configure  '--enable-cflags=-O2 -Wall -g' --enable-zsh-debug --enable-zsh-mem --enable-zsh-mem-debug --enable-zsh-mem-warning --enable-zsh-secure-free --enable-zsh-hash-debug
make


Regards,
-- 
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>

Re: problem building zsh in background

[Philippe Troin]

Danek Duvall <duvall@emufarm.org> writes:

> On Sat, Nov 29, 2003 at 09:43:50PM -0800, Philippe Troin wrote:
> 
> > Why do you want to run configure with nohup?
> 
> In my case, it's more likely that I'd want to run configure from a cron
> script -- nightly builds.
> 
> > I guess I could run the test in a separate, created pty, but that is
> > going to be messy to do portably in configure.
> 
> Maybe a configure flag that forces tcsetpgrp() to be recognized as
> working, and skip the test?  I know that it works properly on my
> platform, so I could use the flag and not worry about whether the build
> will hang or abort because of the test ...

Okay, what about the following behavior:

 - keep the second patch (will fail if ran from cron or any other
   situation where there is no ctty)

 - add a --with-working-tcsetpgrp / --without-working-tcsetpgrp switch
   to force configure to skip the test (instead of failing) and assume
   a working / non-working tcsetpgrp

Would that satisfy everyone?

Phil.

Re: problem building zsh in background

[Bart Schaefer]

On Nov 30, 10:08pm, Philippe Troin wrote:
}
} Okay, what about the following behavior:
} 
}  - keep the second patch (will fail if ran from cron or any other
}    situation where there is no ctty)
} 
}  - add a --with-working-tcsetpgrp / --without-working-tcsetpgrp switch
}    to force configure to skip the test (instead of failing) and assume
}    a working / non-working tcsetpgrp
} 
} Would that satisfy everyone?

Other than that it should just be --with-tcsetpgroup (what's the point of
"working"?  Is there a --with-broken-tcsetpgroup option?), I think that
sounds fine.

Re: problem building zsh in background

[Jens Petersen]

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    PT> - add a --with-working-tcsetpgrp /
    PT>    --without-working-tcsetpgrp switch to force
    PT>    configure to skip the test (instead of failing)
    PT>    and assume a working / non-working tcsetpgrp

    PT> Would that satisfy everyone?

Sounds ok to me. :)

Jens

Re: problem building zsh in background

[Philippe Troin]

[-- Attachment #1: Type: text/plain, Size: 581 bytes --]

Jens Petersen <petersen@redhat.com> writes:

> >>>>> "PT" == Philippe Troin <phil@fifi.org> writes:
> 
>     PT> - add a --with-working-tcsetpgrp /
>     PT>    --without-working-tcsetpgrp switch to force
>     PT>    configure to skip the test (instead of failing)
>     PT>    and assume a working / non-working tcsetpgrp
> 
>     PT> Would that satisfy everyone?
> 
> Sounds ok to me. :)

Okay, here's the patch that implements --with-tcsetpgrp. Following
Bart Schaefer <schaefer@brasslantern.com>'s advice, I've changed the
configure switch to --with-tcsetpgrp.

Please test.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: zsh-bgconfigure-3.patch --]
[-- Type: text/x-patch, Size: 2667 bytes --]

Index: zshconfig.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/zshconfig.ac,v
retrieving revision 1.42
diff -u -r1.42 zshconfig.ac
--- zshconfig.ac	13 Nov 2003 14:34:34 -0000	1.42
+++ zshconfig.ac	3 Dec 2003 01:08:15 -0000
@@ -528,7 +528,7 @@
 dnl SYSV-derived systems.
 dnl On HPUX, Hcurses is reported to work better than curses.
 AC_ARG_WITH(curses-terminfo,
-[  --with-curses-terminfo     use terminfo support from curses library],
+[  --with-curses-terminfo  use terminfo support from curses library],
 [if test x$withval = xyes; then
   termcap_curses_order="tinfo curses ncurses termcap"
   AC_SEARCH_LIBS(tigetstr, [$termcap_curses_order])
@@ -1576,24 +1576,53 @@
 dnl if found tcsetpgrp, test to see if it actually works
 dnl for instance, BeOS R4.51 does not support it yet
 dnl -----------
-if test -t 0 && test $ac_cv_func_tcsetpgrp = yes; then
+AC_ARG_WITH(tcsetpgrp,
+[  --with-tcsetpgrp        assumes that tcsetpgrp() exists and works correctly],[
+case "x$withval" in
+    xyes) zsh_working_tcsetpgrp=yes;;
+    xno)  zsh_working_tcsetpgrp=no;;
+    *)    AC_ERROR([please use --with-tcsetpgrp=yes or --with-tcsetpgrp=no]);;
+esac],[zsh_working_tcsetpgrp=check])
+if test "x$ac_cv_func_tcsetpgrp" = xyes; then
+case "x$zsh_working_tcsetpgrp" in
+  xcheck)
+    trap "" SIGTTOU > /dev/null 2>&1 || :
     AC_CACHE_CHECK(if tcsetpgrp() actually works,
     zsh_cv_sys_tcsetpgrp,
     [AC_TRY_RUN([
 #include <sys/types.h>
 #include <unistd.h>
+#include <fcntl.h>
 main() {
+    int fd;
     int ret;
-    ret=tcsetpgrp(0, tcgetpgrp(0));
-    exit(ret<0);
+    fd=open("/dev/tty", O_RDWR);
+    if (fd < 0) exit(2);
+    ret=tcsetpgrp(fd, tcgetpgrp(fd));
+    if (ret < 0) exit(1);
+    exit(0);
 }
 ],
-      zsh_cv_sys_tcsetpgrp=yes,
-      zsh_cv_sys_tcsetpgrp=no,
-      zsh_cv_sys_tcsetpgrp=yes)])
-    if test $zsh_cv_sys_tcsetpgrp = no; then
-      AC_DEFINE(BROKEN_TCSETPGRP)
-    fi
+      zsh_cv_sys_tcsetpgrp=yes, [
+case $? in
+    1) zsh_cv_sys_tcsetpgrp=no;;
+    2) zsh_cv_sys_tcsetpgrp=notty;;
+    *) zsh_cv_sys_tcsetpgrp=error;;
+esac
+      ], zsh_cv_sys_tcsetpgrp=yes)])
+    case "x$zsh_cv_sys_tcsetpgrp" in
+      xno)    AC_DEFINE(BROKEN_TCSETPGRP);;
+      xyes)   :;;
+      xnotty) AC_MSG_ERROR([no controlling tty
+Try running configure with --with-tcsetpgrp or --without-tcsetpgrp]);;
+      *)      AC_MSG_ERROR([unexpected return status]);;
+    esac
+    trap - SIGTTOU > /dev/null 2>&1 || :
+    ;;
+  xyes) :;;
+  xno)  AC_DEFINE(BROKEN_TCSETPGRP);;
+  *)    AC_MSG_ERROR([unexpected value zsh_working_tcsetpgrp=$zsh_working_tcsetpgrp]);;
+esac
 fi
 
 dnl -----------

Re: problem building zsh in background

[Jens Petersen]

>>>>> "PT" == Philippe Troin <phil@fifi.org> writes:

    PT> Okay, here's the patch that implements
    PT> --with-tcsetpgrp. Following Bart Schaefer
    PT> <schaefer@brasslantern.com>'s advice, I've changed
    PT> the configure switch to --with-tcsetpgrp.

    PT> Please test.

Sorry, I didn't get round to testing this patch yet, but I'm
still curious what platform this test is needed for: ie on
which platforms is tcsetpgrp broken?  If for example it has
always worked correctly with glibc and most other platforms
then it would be nice if it could just be skipped for those
systems, or rather just run on the affected platforms: that
would simplify things for the builder IMHO and remove the
need for another (somewhat cryptic) configure option.

Jens

Re: problem building zsh in background

[Philippe Troin]

Jens Petersen <petersen@redhat.com> writes:

> >>>>> "PT" == Philippe Troin <phil@fifi.org> writes:
> 
>     PT> Okay, here's the patch that implements
>     PT> --with-tcsetpgrp. Following Bart Schaefer
>     PT> <schaefer@brasslantern.com>'s advice, I've changed
>     PT> the configure switch to --with-tcsetpgrp.
> 
>     PT> Please test.
> 
> Sorry, I didn't get round to testing this patch yet, 

Then please test :-)

> but I'm still curious what platform this test is needed for: ie on
> which platforms is tcsetpgrp broken?  

>From the comments I've seen, BeOS has tcsetpgrp() but it does not
work.

> If for example it has always worked correctly with glibc and most
> other platforms 

It will always work on a real and recent enough unix variant. BeOS is
POSIX-like enough, but does not support all the aspects of job control
(apparently).

> then it would be nice if it could just be skipped for those systems,
> or rather just run on the affected platforms: 

This is against the autoconf philosophy of testing things rather than
assuming them for a given platform.

> that would simplify things for the builder IMHO and remove the need
> for another (somewhat cryptic) configure option.

You're the one who wanted this option for your build system. I've
accomodated you ;-) For me, failing when not running on a terminal
(which is a corner case for 99.99% (made out figure) of zsh's users)
is perfectly acceptable option.

Phil.