Failed kyua tests with regular users

[Juan RP]

Hi,

After running kyua for its test suite in a Linux x86_64 system (with
my regular user) I'm seeing that some tests failed with:

broken: Could not clean up test work directory: Failed to clean up '/
tmp/kyua.4TDazC'

The only known error I've found in the strace output comes from this:
...
symlink("/usr/tests/kyua-cli/utils/process/helpers", "root/helpers") =
0
...
chmod("/tmp/kyua.wR3dQm/run/root/helpers", 0700) = -1 EPERM (Operation
not permitted)
write(3, "20120307-130558 W 24445 utils/fs"..., 137) = 137
lstat("/tmp/kyua.wR3dQm/run/root/helpers", {st_mode=S_IFLNK|0777,
st_size=41, ...}) = 0
unlink("/tmp/kyua.wR3dQm/run/root/helpers") = 0
...

Haven't looked at the code but this chmod(2) call probably is trying
to change perms to the file the symlinks points to.... or am I wrong?

Thanks.

[Julio Merino]

On 3/7/12 1:26 PM, Juan RP wrote:
> Hi,
>
> After running kyua for its test suite in a Linux x86_64 system (with
> my regular user) I'm seeing that some tests failed with:
>
> broken: Could not clean up test work directory: Failed to clean up '/
> tmp/kyua.4TDazC'

What test is this? What Linux distribution and libc version?

Try to run the failing test with "kyua debug foo/bar:baz" and see what
the output looks like. It may provide some hints.

Is it there any useful information in ~/.kyua/logs/ regarding this
particular failure? (I don't think so because this is one test failing
and not kyua itself, but still.)

Note that Linux does not implement lchmod() which Kyua needs in some
circumstances, so this might be related. What is HAVE_WORKING_LCHMOD in
config.h? It might just be that the tests checking this feature are not
working properly... although they run fine in my test Linux x86_64 machine.

[Juan RP]

There are a bunch of them that failed due to this error, example:

utils/process/children_test:exec__basename_only -> broken: Could not

clean up test work directory: Failed to clean up '/tmp/

kyua.e3xpZl' [0.004s]
utils/process/children_test:exec__relative_path -> broken: Could not

clean up test work directory: Failed to clean up '/tmp/

kyua.VH30ac' [0.009s]

Linux x86_64, glibc-2.14.1, gcc-4.6.3, kernel 3.2.9.

Running a failed test with debug doesn't show anything useful, AFAIK:

$ kyua debug utils/process/children_test:exec__relative_path
20120307-134630 D 30915 utils/process/children.cpp:319: Spawned
process 30916: stdout=out, stderr=err
20120307-134630 D 30915 utils/process/children.cpp:154: Waiting for
pid=30916, no timeout
20120307-134630 D 30915 utils/process/children.cpp:161: Sending KILL
signal to process group 30916
utils/process/children_test:exec__relative_path -> broken: Could not
clean up test work directory: Failed to clean up '/tmp/kyua.J83QGf'
$

Regarding lchmod:

checking for a working lchmod... no
HAVE_WORKING_LCHMOD is unset.

Let me know if you need more info.

[Julio Merino]

Yeah, a few more things please:

What is left in the /tmp/kyua.XXXXXX directories after the failure? A
ls -l would be useful here.

What is /tmp? Is it a symlink? What filesystem?

Also, please run this:

kyua --logfile=some-name.log --loglevel=debug debug
utils/process/children_test:exec__relative_path

and provide the contents of some-name.log. It may actually yield some
useful data.

Thanks!

[Juan RP]

On 7 mar, 14:51, Juan RP <xtra...@gmail.com> wrote:

> Regarding lchmod:
>
> checking for a working lchmod... no
> HAVE_WORKING_LCHMOD is unset.
>
> Let me know if you need more info.

Looks like lchmod is only defined with __USE_BSD:

#ifdef __USE_BSD
/* Set file access permissions for FILE to MODE.
If FILE is a symbolic link, this affects the link itself
rather than its target. */
extern int lchmod (__const char *__file, __mode_t __mode)
__THROW __nonnull ((1));
#endif

[Juan RP]

On 7 mar, 14:56, Julio Merino <j...@julipedia.org> wrote:
> Yeah, a few more things please:
>
> What is left in the /tmp/kyua.XXXXXX directories after the failure?  A
> ls -l would be useful here.

Looks like the directory is completely removed.

> What is /tmp?  Is it a symlink?  What filesystem?

Nope, not a symlink.

tmpfs on /tmp type tmpfs (rw,relatime):
drwxrwxrwt 26 root root 540 mar 7 15:01 tmp

> Also, please run this:
>
> kyua --logfile=some-name.log --loglevel=debug debug
> utils/process/children_test:exec__relative_path

Showing the last useful lines:

20120307-140149 D 728 engine/isolation.cpp:115: Checking for pending
interrupt signals
20120307-140149 I 728 utils/fs/operations.cpp:502: Starting cleanup of
'/tmp/kyua.drvg3i'
20120307-140149 W 728 utils/fs/operations.cpp:136: lchmod(3) was not
available at compilation time; work directory cleanup might fail
unexpectedly
20120307-140149 W 728 utils/fs/operations.cpp:301: Failed to chmod '/
tmp/kyua.drvg3i/run/root/helpers' to 448: Operation not permitted
20120307-140149 W 728 utils/fs/operations.cpp:511: Cleanup of '/tmp/
kyua.drvg3i' failed
20120307-140149 D 728 engine/isolation.cpp:115: Checking for pending
interrupt signals
20120307-140149 I 728 utils/cmdline/ui.cpp:66: stdout: utils/process/

children_test:exec__relative_path -> broken: Could not clean up test

work directory: Failed to clean up '/tmp/kyua.drvg3i'
20120307-140149 I 728 cli/main.cpp:283: Clean exit with code 1

[Juan RP]

On 7 mar, 14:59, Juan RP <xtra...@gmail.com> wrote:

> Looks like lchmod is only defined with __USE_BSD:
>
> #ifdef __USE_BSD
> /* Set file access permissions for FILE to MODE.
>    If FILE is a symbolic link, this affects the link itself
>    rather than its target.  */
> extern int lchmod (__const char *__file, __mode_t __mode)
>      __THROW __nonnull ((1));
> #endif

And looks like lchmod is not implemented on Linux, AFAIK.

[Julio Merino]

On 3/7/12 2:06 PM, Juan RP wrote:
>
>
> On 7 mar, 14:56, Julio Merino<j...@julipedia.org> wrote:
>> Yeah, a few more things please:

[...]

>> Also, please run this:
>>
>> kyua --logfile=some-name.log --loglevel=debug debug
>> utils/process/children_test:exec__relative_path
>
> Showing the last useful lines:
>

> 20120307-140149 W 728 utils/fs/operations.cpp:301: Failed to chmod '/
> tmp/kyua.drvg3i/run/root/helpers' to 448: Operation not permitted

[...]

Ah hah. I haven't tried to reproduce it here yet, but I think I know
why this happens. Can you try with the attached patch please?

Also, are any of the tests under utils/fs failing?

[Juan RP]

On 7 mar, 15:43, Julio Merino <j...@julipedia.org> wrote:

> Ah hah.  I haven't tried to reproduce it here yet, but I think I know
> why this happens.  Can you try with the attached patch please?

Great! this patch works:

1011/1011 passed (0 failed)

> Also, are any of the tests under utils/fs failing?

Nope, just those two.

Thanks!

[Juan RP]

On 7 mar, 15:50, Juan RP <xtra...@gmail.com> wrote:

> Great! this patch works:
>
> 1011/1011 passed (0 failed)

Here's the output of 'kyua report' just for the record:

[juan@nocturno ~]$ kyua report
===> Skipped tests
engine/atf_iface/runner_test:run_test_case__required_user__root__ok -
> skipped: Requires root privileges [0.000s]
engine/atf_iface/
runner_test:run_test_case__required_user__unprivileged__drop ->
skipped: Requires root privileges [0.000s]
engine/atf_iface/
runner_test:run_test_case__required_user__unprivileged__skip ->
skipped: Requires root privileges [0.000s]
engine/atf_iface/
test_case_test:check_requirements__required_memory__fail -> skipped:
Don't know how to query the amount of physical memory [0.002s]
engine/drivers/debug_test_test:TODO -> skipped: Not implemented
[0.002s]
engine/drivers/run_tests_test:TODO -> skipped: Not implemented
[0.002s]
utils/passwd_test:drop_privileges -> skipped: Requires root
privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__busy -> skipped:
Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__links -> skipped:
Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__nested -> skipped:
Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__root__many ->
skipped: Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__root__one -> skipped:
Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__subdir__many ->
skipped: Requires root privileges [0.000s]
utils/fs/operations_test:cleanup__mount_point__subdir__one ->
skipped: Requires root privileges [0.000s]
utils/fs/operations_test:unmount__fail -> skipped: Requires root
privileges [0.000s]
utils/fs/operations_test:unmount__ok -> skipped: Requires root
privileges [0.000s]
===> Summary
Action: 7
Test cases: 1011 total, 16 skipped, 0 expected failures, 0 broken, 0
failed
Total time: 19.747s
[juan@nocturno ~]$

Thanks for your quick fix, cheers.

[Julio Merino]

On 3/7/12 2:50 PM, Juan RP wrote:
> On 7 mar, 15:43, Julio Merino<j...@julipedia.org> wrote:
>
>> Ah hah. I haven't tried to reproduce it here yet, but I think I know
>> why this happens. Can you try with the attached patch please?
>
> Great! this patch works:
>
> 1011/1011 passed (0 failed)

Cool! I'll submit this later. Would like to reproduce it first to
evaluate any side-effects though.

Thanks for the quick turnaround.

[Julio Merino]

Slightly-different fix submitted:

http://code.google.com/p/kyua/source/detail?r=38acd560ecd5252d45936b6d53c4246859c87f1d

[Juan Romero Pardines]

El día 7 de marzo de 2012 18:35, Julio Merino <jm...@google.com> escribió:

> Slightly-different fix submitted:
>
> http://code.google.com/p/kyua/source/detail?r=38acd560ecd5252d45936b6d53c4246859c87f1d

Thanks, will apply it in the xbps package.