coreutils icon indicating copy to clipboard operation
coreutils copied to clipboard

Android CI: regression on `test_chroot::test_preference_of_userspec`

Open niyaznigmatullin opened this issue 3 years ago • 1 comments
trafficstars

  • Seems that happened after merging #3908 on Android CI
---- test_chroot::test_preference_of_userspec stdout ----
current_directory_resolved: 
run: whoami
result.stdout = u0_a67

result.stderr = 
current_directory_resolved: 
run: id -g -n
result.stdout = u0_a67

result.stderr = 
current_directory_resolved: 
mkdir: /data/data/com.termux/files/usr/tmp/.tmpI6xNwk/a
run: /data/data/com.termux/files/home/coreutils/target/debug/coreutils chroot a --user fake -G ABC,DEF --userspec=u0_a67:u0_a67
thread 'test_chroot::test_preference_of_userspec' panicked at 'Program must be run first', tests/common/util.rs:152:19
zzz

niyaznigmatullin avatar Sep 14 '22 09:09 niyaznigmatullin

Interesting, it's indeed this line that fails:

result.code_is(125);

which I added in that PR. But the it should definitely have run the program by that point. So I dug around and found this in the standard library on ExitStatus::code (which is used to get the code used by code_is):

On Unix, this will return None if the process was terminated by a signal.

This suggests that the command was terminated by a signal and hence doesn't have an ExitCode, so I think this uncovered an issue rather than created one. We need to make sure that the command is not terminated prematurely.

Although, I guess that if we can't figure that out we should probably disable this test (or remove the line I added).

tertsdiepraam avatar Sep 14 '22 18:09 tertsdiepraam

Oh, this is expected on Android because of the seccomp filter, which will send a SIGSYS to any process that makes a chroot syscall, terminating it unless explicitly handled. See the "Seccomp restrictions" check box in this relevant comment. The correct solution here would probably be to skip that particular check on Android, or skip the test entirely (chroot should theoretically work in an appropriately configured Android development environment, but that's so rare we decided not to explicitly support it, just not intentionally break it).

jtracey avatar Sep 26 '22 22:09 jtracey

Was disabled in #4005, I think this can be closed now.

jtracey avatar Oct 13 '22 04:10 jtracey