On 2/19/19 10:13 AM, Daniel P. Berrangé wrote:
> When we run "certtool | head -1" the latter command is likely to
> complete and exit before certtool has written everything it wants to
> stderr. In at least the RHEL-7 gnutls 3.3.29 this causes certtool to
> quit with broken pipe before it has finished writing the desired
> output file to disk. This causes non-deterministic failures of the
> iotest 233 because the certs are sometimes zero length files.
> If certtool fails the "head -1" means we also loose any useful error
> message it would have printed.
> 
> Thus this patch gets rid of the pipe and post-processes the output in a
> more flexible & reliable manner.
> 

Better than my attempt.

> Reported-by: Thomas Huth <th...@redhat.com>
> Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
> ---
>  tests/qemu-iotests/common.tls | 48 +++++++++++++++++++++++------------
>  1 file changed, 32 insertions(+), 16 deletions(-)

As Thomas pointed out, it is not parallel-safe, but that's a bigger
issue with all of the iotests, so not this patch's problem.

> 
> diff --git a/tests/qemu-iotests/common.tls b/tests/qemu-iotests/common.tls
> index eae81789bb..6cf11ed383 100644
> --- a/tests/qemu-iotests/common.tls
> +++ b/tests/qemu-iotests/common.tls
> @@ -29,6 +29,17 @@ tls_x509_cleanup()
>  }
>  
>  
> +tls_certtool()
> +{
> +    certtool "$@" 1>certtool.log 2>&1

I tend to use '>' instead of '1>', but they are identical.

> +    if test "$?" = 0; then
> +      head -1 certtool.log

Technically, POSIX says 'head -1' is not portable (it was historical
practice, but a wording change in POSIX 2001 made it invalid, which
wasn't fixed until POSIX 2008 - and there are historical versions of GNU
coreutils which went out of their way to reject the usage, although that
has since been fixed); the portable spelling these days is 'head -n1'.
But as the test was already using 'head -1', I'm not going to make you
switch it.

Reviewed-by: Eric Blake <ebl...@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Reply via email to