pdsh-2.24 fails unit tests on Mac OS X 10.6 x86_64

[GoogleCodeExporter]

Hello Mark!  I tried to update the Fink pdsh package, and while the build 
seemed to run OK, I saw a few failures from the test suite:

--- begin paste ---
...
make  check-TESTS
not ok - 1 working success
#   /bin/true
ok 2 - test runs if prerequisite is satisfied
ok 3 - tests clean up after themselves
ok 4 - tests clean up even after a failure
ok 5 - failure to clean up causes the test to fail
ok 6 - pdsh runs
ok 7 - pdsh -V works
ok 8 - pdsh -L works
ok 9 - pdsh -h works
ok 10 - rcmd/exec module is built
ok 11 - pdsh -N option works
ok 12 # skip -u option is functional (missing LONGTESTS)
ok 13 - -f sets fanout
ok 14 - -l sets remote username
ok 15 - -t sets connect timeout
ok 16 - -u sets command timeout
ok 17 - command timeout 0 by default
ok 18 - -b enables batch mode
ok 19 - pdsh -N option works
# failed 1 among 19 test(s)
1..19
FAIL: ./t0001-basic.sh
ok 1 - working xstrerrorcat
ok 2 - working pipecmd
# passed all 2 test(s)
1..2
PASS: ./t0002-internal.sh
ok 1 - hostname range expansion works
ok 2 - host range expansion does not strip leading zeros
ok 3 - host range expansion handles mixed size suffixes
ok 4 - host range expansion works with "," embedded in range
ok 5 - host range expansion works with 2 sets of brackets
ok 6 - pdsh -x option works
ok 7 - pdsh -x option works with ranges
ok 8 - pdsh -x option works with ranges (gnats:118)
ok 9 - pdsh -x option works with non-numeric suffix (gnats:120)
ok 10 - pdsh -w- reads from stdin
ok 11 - pdsh -w- can be used with other -w args
ok 12 - WCOLL environment variable works
ok 13 - ranges can be embedded in wcoll files
ok 14 - ^file works
ok 15 - -x ^file works
ok 16 - ^file works with other args
ok 17 - Multiple ^file args
ok 18 - Multiple -w^file
ok 19 - -^file excludes hosts in file
ok 20 - ^file errors out if file doesnt exist
ok 21 - host exclusion with "-" works
ok 22 - regex filtering works
ok 23 - regex exclusion works
ok 24 - regex exclusion works from -x
ok 25 - multiple -w options
# passed all 25 test(s)
1..25
PASS: ./t0003-wcoll.sh
ok 1 - PDSH_MODULE_DIR functionality
ok 2 - module A takes precedence over B
ok 3 - pdsh -M B ativates module B
ok 4 - PDSH_MISC_MODULES option works
ok 5 - -M option overrides PDSH_MISC_MODULES environment var
ok 6 - pdsh help string correctly displays options of loaded modules
ok 7 - Loading conflicting module with -M causes error
ok 8 - Conflicting modules dont run init()
ok 9 - Force loaded module runs init()
ok 10 - New conflicting module does not run init() with -M
# passed all 10 test(s)
1..10
PASS: ./t0004-module-loading.sh
ok 1 - pdsh -l sets username for all hosts
ok 2 - Can set remote username via user@hosts
ok 3 - user@hosts works for a subset of hosts
ok 4 - Can set rcmd_type via rcmd_type:hosts
ok 5 - Can set rcmd_type and user via rcmd_type:user@hosts
# passed all 5 test(s)
1..5
PASS: ./t0005-rcmd_type-and-user.sh
ok 1 - Creating pdcp link to pdsh binary
ok 2 - Creating rpdcp link to pdsh binary
ok 3 - pdcp runs
ok 4 - rpdcp runs
ok 5 - pdcp -V works
ok 6 - pdcp -q works
ok 7 - -e sets remote program path
ok 8 - PDSH_REMOTE_PDCP_PATH sets remote program path
ok 9 - -f sets fanout
ok 10 - -l sets remote username
ok 11 - -t sets connect timeout
ok 12 - -u sets command timeout
ok 13 - command timeout 0 by default
ok 14 - Have pcptest rcmd module
ok 15 - pdcp basic functionality
ok 16 - rpdcp basic functionality
ok 17 - initialize directory tree
ok 18 - pdcp -r works
ok 19 - rpdcp -r works
# passed all 19 test(s)
1..19
PASS: ./t0006-pdcp.sh
ok 1 - dshbak functionality
ok 2 - dshbak -c does not coalesce different length output
ok 3 - dshbak -c properly compresses multi-digit suffixes
ok 4 - dshbak -c properly compresses prefix with embedded numerals
ok 5 - dshbak -c does not strip leading zeros
ok 6 - dshbak -c does not coalesce different zero padding
ok 7 - dshbak -c properly coalesces zero padding of "00"
ok 8 - dshbak -c can detect suffixes
not ok 9 - dshbak -c can detect suffix with numeral # TODO known breakage
ok 10 - dshbak -d functionality
ok 11 - dshbak -f functionality
ok 12 - dshbak -f without -d fails
ok 13 - dshbak -d fails when output dir does not exist
not ok - 14 dshbak -d fails gracefully for non-writable dir
#   
#     mkdir test_output &&
#     chmod 500 test_output &&
#     echo -e "foo0: bar" | dshbak -d test_output 2>&1 | tee logfile | \
#        grep "Failed to open output file"  &&
#     rm -rf test_output logfile
#   
# still have 1 known breakage(s)
# failed 1 among remaining 13 test(s)
1..14
FAIL: ./t1000-dshbak.sh
# passed all 0 test(s)
1..0 # SKIP skipping genders tests, genders module not available
PASS: ./t1001-genders.sh
ok 1 - dshgroup options are active
ok 2 - dshgroup -g option works
ok 3 - dshgroup -g option works with more than one group
ok 4 - dshgroup -X option works
ok 5 - dshgroup -X option works with -w
# passed all 5 test(s)
1..5
PASS: ./t1002-dshgroup.sh
# passed all 0 test(s)
1..0 # SKIP skipping slurm tests, slurm module not available
PASS: ./t1003-slurm.sh
====================
2 of 10 tests failed
====================
...
--- end paste ---

What additional information can I provide that may be of help?

thanks,  
-Steve

Original issue reported on code.google.com by hakamad...@gmail.com on 2 Mar 2011 at 1:50

[GoogleCodeExporter]

Thank you for running the tests!

> make  check-TESTS
> not ok - 1 working success

This is a basic failure of the testsuite itself, which is based on the 
testsuite for git.
Does your system have a "/bin/true"?

> #       /bin/true

> not ok - 14 dshbak -d fails gracefully for non-writable dir
> #       
> #         mkdir test_output &&
> #         chmod 500 test_output &&
> #         echo -e "foo0: bar" | dshbak -d test_output 2>&1 | tee logfile | \
> #            grep "Failed to open output file"  &&
> #         rm -rf test_output logfile
> #       
> # still have 1 known breakage(s)
> # failed 1 among remaining 13 test(s)

This one tests the new dshbak -d functionality on a non writable directory.
dshbak should fail with the string "Failed to open output file".
After you run the tests,  any failed test scripts should leave 
a "trash-directory.<testid>" directory. Can you check for a
trash-directory.t1000-dshbak under 'tests' and see if the file
'logfile' contains anything? Otherwise you could try running the
bits of the test by hand:


  mkdir test_output
  chmod 500 test_output
  echo -e "foo0: bar" | dshbak -d test_output 

and send me the results. Maybe the grep is too simple.

> 1..14
> FAIL: ./t1000-dshbak.sh


Thanks, 
mark

Original comment by mark.gro...@gmail.com on 2 Mar 2011 at 5:47

• Changed state: Accepted

[GoogleCodeExporter]

> > make  check-TESTS
> > not ok - 1 working success
> 
> This is a basic failure of the testsuite itself, which is based on the 
testsuite for git.
> Does your system have a "/bin/true"?
>  
> > #       /bin/true

Nope; Darwin has /usr/bin/true.

> > # still have 1 known breakage(s)
> > # failed 1 among remaining 13 test(s)
> 
> This one tests the new dshbak -d functionality on a non writable directory.
> dshbak should fail with the string "Failed to open output file".
> After you run the tests,  any failed test scripts should leave 
> a "trash-directory.<testid>" directory. Can you check for a
> trash-directory.t1000-dshbak under 'tests' and see if the file
> 'logfile' contains anything? Otherwise you could try running the
> bits of the test by hand:
> 
> 
>   mkdir test_output
>   chmod 500 test_output
>   echo -e "foo0: bar" | dshbak -d test_output 
>   
> and send me the results. Maybe the grep is too simple.

$ sudo ls -lR trash-directory.t1000-dshbak
total 16
-rw-r--r--  1 fink-bld  fink-bld   0 Mar  2 08:45 logfile
-rw-r--r--  1 fink-bld  fink-bld  78 Mar  2 08:45 output
-rw-r--r--  1 fink-bld  fink-bld  28 Mar  2 08:45 test_input
dr-x------  2 fink-bld  fink-bld  68 Mar  2 08:45 test_output

trash-directory.t1000-dshbak/test_output:

$ cat trash-directory.t1000-dshbak//output
----------------
foo00s0foo01s0foo02s0foo1s0foo3s0foo5s0
----------------
bar

$ cat trash-directory.t1000-dshbak//test_input
test
input
file
 foo
bar  

$ mkdir test_output && chmod 500 test_output && echo -e "foo0: bar" | 
../../scripts/dshbak -d test_output
dshbak: Fatal: Failed to open output file 'test_output/foo0': Permission denied

Does that help?  This makes me suspect that the issue may have to do with the 
Fink build environment (that last command I ran as myself, rather than as the 
Fink build user).

-steve

Original comment by hakamad...@gmail.com on 2 Mar 2011 at 6:11

[GoogleCodeExporter]

I will replace the /bin/true for the basic test success test with ':'

Is there a way to run the commands

 $ mkdir test_output && chmod 500 test_output && echo -e "foo0: bar" | ../../scripts/dshbak -d test_output


in the Fink build environment to see where the test is failing? It is probably
just a bit of a fragile test. I'll try to think of a way to make it more robust.

Original comment by mark.gro...@gmail.com on 2 Mar 2011 at 6:40

[GoogleCodeExporter]

Does the Fink build run as a privileged user? That might explain
the failure of the dshbak -d test. Can you try applying the attached patch
and see if this resolved this particular test failure?

Original comment by mark.gro...@gmail.com on 5 Mar 2011 at 12:19

Attachments:

• tests-t1000-dshbak-sanity.patch

[GoogleCodeExporter]

This issue was updated by revision r1296.

This commit fixes one of the two failing test cases for this issue.

Original comment by mark.gro...@gmail.com on 9 Mar 2011 at 3:24

[GoogleCodeExporter]

This issue was updated by revision r1297.

Possible fix for failure in t1000-dshbak.sh

Original comment by mark.gro...@gmail.com on 9 Mar 2011 at 3:25

[GoogleCodeExporter]

I have tagged and uploaded pdsh-2.25 which I hope has resolved this issue.
If you can, let me know so I can close this issue.

Thanks!

Original comment by mark.gro...@gmail.com on 9 Mar 2011 at 3:38

[GoogleCodeExporter]

Mark,  

Thanks for the update!  2.25 fixes the initial failure (the /bin/true issue), 
but I'm still seeing the same failure from t5000-dshbak.sh.  I'm sorry I didn't 
respond to your earlier questions; it looks like you've now rolled the SANITY 
patch into your release.

$ sudo ls -l trash-directory.t5000-dshbak/
total 16
-rw-r--r--  1 fink-bld  fink-bld   0 Mar  9 11:10 logfile
-rw-r--r--  1 fink-bld  fink-bld  78 Mar  9 11:10 output
-rw-r--r--  1 fink-bld  fink-bld  28 Mar  9 11:10 test_input
dr-x------  2 fink-bld  fink-bld  68 Mar  9 11:10 test_output

$ sudo cat trash-directory.t5000-dshbak/output
----------------
foo00s0foo01s0foo02s0foo1s0foo3s0foo5s0
----------------
bar

$ cat trash-directory.t5000-dshbak/test_input 
test
input
file
 foo
bar  

-Steve

Original comment by hakamad...@gmail.com on 9 Mar 2011 at 4:22

[GoogleCodeExporter]

Yeah, the SANITY patch is definitely required if running as root or other 
privileged user and I hoped it would also solve the problem described in this 
issue as well.

Is there a way you could apply the attached patch, which adds set -x before
the affected test and adds debug and verbose output, and rerun under fink build?

Original comment by mark.gro...@gmail.com on 9 Mar 2011 at 5:21

Attachments:

• pdsh-t5000-dshbak-debug.patch

[GoogleCodeExporter]

This issue was updated by revision r1314.


The test for dshbak -d on non-writable directiory was occaisionally
failing when cleaning up the directory and logfile. This is not
part of the test, so we don't care if the rm fails.

Original comment by mark.gro...@gmail.com on 3 Apr 2011 at 6:28