generic/397: be compatible with ignored SIGPIPE
PATCH 1/1 generic/397: be compatible with ignored SIGPIPE
From: Eric Biggers <[email protected]>
If generic/397 is executed in an environment with SIGPIPE ignored, it fails because the 'yes' program prints an error message:
yes: standard output: Broken pipe
yes: write error
This can be reproduced with:
trap '' SIGPIPE; ./check generic/397
Fix it by generating the string of 255 y's using just 'head' and 'tr' instead of 'yes', 'head', and 'tr'.
Although it's not really a good idea to execute xfstests with SIGPIPE ignored, this is the only test I've noticed where it causes a problem, so it might as well be fixed in the test.
It would be much nicer to prevent this problem for all tests by making the 'check' script restore the default SIGPIPE handler. But that isn't straightforward because bash's 'trap' builtin doesn't allow un-ignoring signals that were ignored on entry to the shell.
--- tests/generic/397 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tests/generic/397 +1 -1
@@ -69,7 +69,7 @@ for dir in $SCRATCH_MNT/edir $SCRATCH_MNT/ref_dir; do touch $dir/empty > /dev/null $XFS_IO_PROG -t -f -c "pwrite 0 4k" $dir/a > /dev/null $XFS_IO_PROG -t -f -c "pwrite 0 33k" $dir/abcdefghijklmnopqrstuvwxyz > /dev/null - maxname=$(yes | head -255 | tr -d '\n') # 255 character filename + maxname=$(head -c 255 /dev/zero | tr '\0' y) # 255 character filename $XFS_IO_PROG -t -f -c "pwrite 0 1k" $dir/$maxname > /dev/null ln -s a $dir/symlink ln -s abcdefghijklmnopqrstuvwxyz $dir/symlink2
Signature · 1 line
2.13.1.508.gb3defc5cc-goog
Quoted 10 lines · Eric Biggers
From: Eric Biggers <[email protected]>
If generic/397 is executed in an environment with SIGPIPE ignored, it fails because the 'yes' program prints an error message:
yes: standard output: Broken pipe
yes: write errorThis can be reproduced with:
Quoted 8 lines
trap '' SIGPIPE; ./check generic/397
Fix it by generating the string of 255 y's using just 'head' and 'tr' instead of 'yes', 'head', and 'tr'.
Although it's not really a good idea to execute xfstests with SIGPIPE ignored, this is the only test I've noticed where it causes a problem, so it might as well be fixed in the test.
I'm just curious, why do you need to run fstests with SIGPIPE ignored?
Quoted 16 lines
It would be much nicer to prevent this problem for all tests by making the 'check' script restore the default SIGPIPE handler. But that isn't straightforward because bash's 'trap' builtin doesn't allow un-ignoring signals that were ignored on entry to the shell.
Signed-off-by Eric Biggers <[email protected]>--- tests/generic/397 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)tests/generic/397 +0
-0
tests/generic/397 for dir in $SCRATCH_MNT/edir $SCRATCH_MNT/ref_dir; do · line 72
Quoted 5 lines
tests/generic/397 +1
-1@@ -69,7 +69,7 @@ for dir in $SCRATCH_MNT/edir $SCRATCH_MNT/ref_dir; do touch $dir/empty > /dev/null $XFS_IO_PROG -t -f -c "pwrite 0 4k" $dir/a > /dev/null $XFS_IO_PROG -t -f -c "pwrite 0 33k" $dir/abcdefghijklmnopqrstuvwxyz > /dev/null - maxname=$(yes | head -255 | tr -d '\n') # 255 character filename + maxname=$(head -c 255 /dev/zero | tr '\0' y) # 255 character filename
Using perl seems simpler, we have some other tests do similar tasks using perl too.
maxname=$($PERL_PROG -e 'print "y" x 255;')
Thanks,
Eryu
Quoted 10 lines
tests/generic/397 +0
-0$XFS_IO_PROG -t -f -c "pwrite 0 1k" $dir/$maxname > /dev/null ln -s a $dir/symlink ln -s abcdefghijklmnopqrstuvwxyz $dir/symlink2Signature · 6 lines
2.13.1.508.gb3defc5cc-goog -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Eryu,
Quoted 13 lines · Eryu Guan
Quoted 12 lines · Eric Biggers
From: Eric Biggers <[email protected]>
If generic/397 is executed in an environment with SIGPIPE ignored, it fails because the 'yes' program prints an error message:
yes: standard output: Broken pipe
yes: write errorThis can be reproduced with:
trap '' SIGPIPE; ./check generic/397
Quoted 9 lines
Quoted 6 lines
Fix it by generating the string of 255 y's using just 'head' and 'tr' instead of 'yes', 'head', and 'tr'.
Although it's not really a good idea to execute xfstests with SIGPIPE ignored, this is the only test I've noticed where it causes a problem, so it might as well be fixed in the test.
I'm just curious, why do you need to run fstests with SIGPIPE ignored?
It's more of an accidental thing, and I'm likely still going to fix the specific case I encountered where 'check' was being run with SIGPIPE being ignored (regardless of whether this xfstests patch goes in or not). But I think it's an easy problem for others to run into, since sometimes processes ignore SIGPIPE because they want to get write errors instead, but then when doing fork() + exec() they forget to reset the SIGPIPE handler. Notably, Python got this wrong and it wasn't fixed until Python 3, so any programs executing the 'check' script from a Python 2 script will usually get this wrong (see:
https://bugs.python.org/issue1652). And usually everything works fine but every once in a while there is a weird problem like this which has to be debugged.
Quoted 6 lines
Using perl seems simpler, we have some other tests do similar tasks using perl too.
maxname=$($PERL_PROG -e 'print "y" x 255;')
Yes, the perl version works too.
Eric