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

[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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] on 3 Apr 2011 at 6:28