Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-19 Thread David Levine
Ralph wrote:

> I'm not sure why script(1) is run in the background and then immediately
> wait'd for;  is it to just get  byte or few of input without wait-ing?  echo | ...

The test originally did that, but 1) the man page on Linux cautions against
it, as shown by the excerpts that Ken posted, and 2) it failed on two of
the buildbot hosts.  It still fails on those two buildbot hosts (using
$SHELL), so that's not a factor.  I just didn't change it back because of 1).
If piping stdin works, I'm fine with it.

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-19 Thread Ralph Corderoy
Hi Ken,

> - The real problem isn't the tight loop for script(1); it's that when
> this version of script gets an EOF on the "user" side (because the
> input is set to /dev/null)

I'm not sure why script(1) is run in the background and then immediately
wait'd for;  is it to just get https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Lyndon Nerenberg

> On Oct 18, 2016, at 12:51 PM, Ken Hornstein  wrote:
> 
> I noticed that test/install-mh/test-version-check is hanging for me
> on MacOS X.  Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null, and it turns out when THAT happens
> there is apparently a bug in that script that results in a tight loop
> where it keeps calling read(), getting an EOF, and then writing out
> 0 bytes to the pseudo-tty.
> 
> I'm not sure what the solution is here; any ideas?

This sounds suspiciously like it's sandbox(7) related.  MacOS does some really 
stupid things in the name of 'security'.  E.g., push a command into the 
background, and MacOS revokes all network access to/from the process.  I wasted 
a week at Flock, trying to figure out why our Mac buildbot slaves were 
breaking, because of this stupidity.

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
Alright, so what I've figured out is:

- If you background a process in a shell script, it sets stdin to /dev/null.
  Which makes sense; it's just not something I ever thought about.  So
  that explains why stdin for script was set to /dev/null.

- The real problem isn't the tight loop for script(1); it's that when
  this version of script gets an EOF on the "user" side (because the input
  is set to /dev/null) it never writes an EOF to the other side, and
  it ends waiting forever on the slave side for input to acknowledge the
  welcome message.  This was fixed relatively late in the script(1) for
  MacOS X (really, in FreeBSD), and I see the Linux version says:

/*
 * The script(1) is usually faster than shell, so it's a good idea to wait until
 * the previous message has been already read by shell from slave before we
 * write to master. This is necessary especially for EOF situation when we can
 * send EOF to master before shell is fully initialized, to workaround this
 * problem we wait until slave is empty. For example:
 *
 *   echo "date" | script
 *
 * Unfortunately, the child (usually shell) can ignore stdin at all, so we
 * don't wait forever to avoid dead locks...
 *
 * Note that script is primarily designed for interactive sessions as it
 * maintains master+slave tty stuff within the session. Use pipe to write to
 * script(1) and assume non-interactive (tee-like) behavior is NOT well
 * supported.
 */

The last paragraph is the key.

I'm not sure what to do here.  This usage of script(1) seems a bit fragile.
I'd be willing to write a test to skip this test if script(1) doesn't work
right, but I'm not sure how easy that would be.

It occurs to me that since POSIX has standardized pseudo-tty functions, we
could write our own program to run stuff under a pty.  That program would
not be very big.  Other suggestions are welcome.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Lyndon Nerenberg

> On Oct 18, 2016, at 4:21 PM, Ralph Corderoy  wrote:
> 
> I've found a Mac Mini I can SSH into, "15.6.0" if that means anything.

Once I get back online I will have a VM running Sierra (macOS 10.12, aka kernel 
16.0) to add to the buildbot cluster.  I also have an older 32-bit Mini running 
Snow Leopard I can resurrect.

MacOS is getting to be a royal pain in the ass to deal with.

--lyndon


___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>Hm.  At home, running El Capitan, it works.  So, guess it's a bug in the
>older version of "script".  Yeah, THIS works fine on El Capitan:
>
>% script < /dev/null

So, I see that the script(1) on El Capitan (but not the previous version
of MacOS X) says:

 If script reads zero bytes from the terminal, it switches to a mode when
 it only attempts to read once a second until there is data to read.  This
 prevents script from spinning on zero-byte reads, but might cause a
 1-second delay in processing of user input.

The thing I don't understand is, where is standard input for script
being redirected?

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>I've found a Mac Mini I can SSH into, "15.6.0" if that means anything.

Hm.  I have that at home, but not at work (work is slightly older).

>A git clone, brew install of a few things like openssl, and
>
>CPPFLAGS=-I/usr/local/opt/openssl/include \
>LDFLAGS=-L/usr/local/opt/openssl/lib \
>./configure
>
>has it `make all check' OK.

Hm.  At home, running El Capitan, it works.  So, guess it's a bug in the
older version of "script".  Yeah, THIS works fine on El Capitan:

% script < /dev/null

I'll make sure it's not something I messed up on the other machine.

>On `make distcheck', the configure doesn't seem to have the original
>environment overrides passed on to it.
>
>configure: error: openssl/ssl.h not found

You need to pass in DISTCHECK_CONFIGURE_FLAGS (something I always forget
about).

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ken Hornstein
>I assume that it's not failing on this:
>
>if script -S /bin/sh 'echo OK' /dev/null 2>&1 | egrep 'OK' >/dev/null;
>
>because I don't think that MacOS X script supports -S.

Yes, that's correct.

The strange thing is ... the problem is _input_ redirection.  This
works fine on MacOS X:

% script > /dev/null

This hangs script in a tight loop:

% script < /dev/null

And I'm not sure where input redirection happens (I verified that standard
input was set to /dev/null via lsof).

>Does removing the output redirection to /dev/null on lines61 help?  If
>so, that's wierd but we could deal with it. 

I'll experiment some more.

--Ken

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread Ralph Corderoy
Hi,

Ken wrote:
> I noticed that test/install-mh/test-version-check is hanging for me on
> MacOS X.  Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null

I've found a Mac Mini I can SSH into, "15.6.0" if that means anything.
A git clone, brew install of a few things like openssl, and

CPPFLAGS=-I/usr/local/opt/openssl/include \
LDFLAGS=-L/usr/local/opt/openssl/lib \
./configure

has it `make all check' OK.

All 105 tests behaved as expected (1 expected failure)
(1 test was not run)

Just another data point.

On `make distcheck', the configure doesn't seem to have the original
environment overrides passed on to it.

configure: error: openssl/ssl.h not found

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers


Re: [Nmh-workers] Hanging test test/install-mh/test-version-check

2016-10-18 Thread David Levine
Ken wrote:

> I noticed that test/install-mh/test-version-check is hanging for me
> on MacOS X.  Specifically, the "script" command on MacOS X seems to be
> the problem; for reasons I don't understand quite yet when "script" is
> run the input is set to /dev/null, and it turns out when THAT happens
> there is apparently a bug in that script

I assume that it's not failing on this:

if script -S /bin/sh 'echo OK' /dev/null 2>&1 | egrep 'OK' >/dev/null;

because I don't think that MacOS X script supports -S.

Does removing the output redirection to /dev/null on lines61 help?  If
so, that's wierd but we could deal with it. 

I assume that it hangs on the following  line?

run_without_input 'if test -t 0  -a  -t 1  -a  -t 2; then echo tty; fi'

Maybe run that in the background, sleep for a second, then see if the process
is still running?  If so, kill it and test_skip?

David

___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers