coreutils
coreutils copied to clipboard
Android CI: regression on `test_chroot::test_preference_of_userspec`
- 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
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
Noneif 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).
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).
Was disabled in #4005, I think this can be closed now.