Re: Autotest and signal handling

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Wildenhues on 11/16/2008 7:43 AM:
> Signal and job handling in shell is a portability disaster.  Sigh.
> Apologies for not providing a series of small patches, but it didn't
> really fit well with the topic.

Thanks for tackling this.

> 
> Now, I don't think we can get all of (1-7) in a portable fashion.
> Let's concentrate first on getting things to work on a common system
> (say, Bash 3.2 on GNU/Linux, GNU make), and then work to make things
> portable.  As a last measure, turning off parallel execution may be
> one measure to avoid breakage on less capable systems, iff supporting
> them is too much hassles otherwise.

As there are already other parallel issues (think cygwin's fifo
implementation), I tend to agree that it is okay to disable parallel
testing and fall back to reliable serial testing on platforms where we
can't make parallel testing handle signals properly.  But we can sure try
to get parallel working first, especially for the common case of GNU/Linux
and a decent shell.

> Kudos to R. Stevens, by the way.

Does he need mention in the changelog?

> +dnl So what we do is enable shell job control if available, which causes the
> +dnl shell to start each parallel task as its own shell job, thus as a new
> +dnl process group leader.  We then send the signal to all new process groups.

It sounds like if the shell doesn't support job control, then we should
not allow parallel tests?

> +for at_signal in 1 2 15; do
> +dnl This signal handler is not suitable for PIPE: it causes writes.
> +dnl The code that was interrupted may have the errexit, monitor, or xtrace
> +dnl flags enabled, so sanitize.
> +  trap 'set +e +x

For portability to shells that only see options in the first argument to
set, shouldn't this use 'set +ex'?

> +     AS_WARN([caught signal $at_signal, bailing out])

Is there any portable way to list the signal by name, not just number?

> +dnl Unfortunately, ksh93 fork-bombs when we send TSTP, so send STOP
> +dnl if this might be ksh (STOP prevents possible TSTP handlers inside
> +dnl AT_CHECKs from running).  Then stop ourselves.
> +       at_sig=TSTP
> +       test "${TMOUT+set}" = set && at_sig=STOP

Using the very same idea you questioned earlier.  Is there any way to more
reliably detect ksh than whether TMOUT is set?  Does this still work in
bash/zsh if TMOUT was exported?

> +       kill -$at_sig $at_pids 2>/dev/null

Is 'kill -TSTP' or 'kill -STOP' portable?  Or do we have to fall back to
numeric arguments (for that matter, TSTP and STOP don't always map to the
same signal numbers).

> +dnl We got a CONT, so let's go again.  Passing this to all processes
> +dnl in the groups is necessary (because we stopped them), but it may
> +dnl cause changed test semantics; e.g., a sleep will be interrupted.
> +     test -z "$at_pids" || kill -CONT $at_pids 2>/dev/null' TSTP

What do we do about shells, like ash, that choke on "trap ... TSTP"?

$ ash -c 'trap "" TSTP'
trap: bad signal TSTP

> +      trap 'set +x +e

Again, shouldn't this be 'set +xe'?

> +  # We'd like to check this here, too, but some shells do now allow to
> +  # turn off job control.

s/now/not/

> +# Apparently some shells don't get around to creating 'status' any more.
> +# And ksh93 on FreeBSD uses 256 + 13 instead of 128 + 13

That's screwy (since exit status is supposed to be 8 bits).  As a separate
patch, can you please prepare a documentation patch for all the gotcha's
that you have discovered during this exercise, such as FreeBSD's broken
exit status?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkgj3oACgkQ84KuGfSFAYBrCwCg1ZmTSghT68j0oIC17dVCnukO
TkkAoIr9jE2Dgi2CIhUjjmqjrxKtZFx6
=IVIu
-----END PGP SIGNATURE-----