Missing test_must_fail function in Flux testing environment #5862
Comments
|
Can you post the output of
It does. Pointing the flux instance at the sqlite file means that Flux will try to write to it.
You cannot run sharness test scripts outside of the sharness environment. . `dirname $0`/sharness.sh |
|
@grondo Here is the output of perhaps the touch command to create the file for test 11 is failing? |
|
Can you wrap the output in triple-backticks? e.g. It is difficult to read the output with all the markdown formatting. |
|
Are you running the tests as root? I don't think that is tested (or advised) Edit: though I'm not sure that's the issue here. |
within my singularity container I am running as |
Good thought, though I'd think we'd see some sort of error. You can edit the test itself and add some debugging (like |
The touch command is working as expected. The cause of the fail is very strange. |
|
would it be worthwhile to do the |
Well this one failed because you have I don't see any error from your previous output. Was that all the output? Maybe make the following change to that script so we can see the output of flux-start: diff --git a/t/t3203-instance-recovery.t b/t/t3203-instance-recovery.t
index 3ac63c61e..c739a06ec 100755
--- a/t/t3203-instance-recovery.t
+++ b/t/t3203-instance-recovery.t
@@ -87,6 +87,8 @@ test_expect_success 'recovery mode aborts early if content is missing' '
test_expect_success 'recovery mode aborts early if content unwritable' '
touch test2/content.sqlite &&
chmod 400 test2/content.sqlite &&
+ ls -l test2 &&
+ test_must_fail flux start --recovery=$(pwd)/test2 &&
test_must_fail flux start --recovery=$(pwd)/test2 2>nowrite.err &&
grep "no write permission" nowrite.err
'Edited diff to include @chu11's suggestion. |
@grondo @chu11 New output shows that ls works as expected but I get an error |
Ah, this error is because I'm beginning to think that read and write-only permissions are not working in your environment, perhaps because of fakeroot. Can you try the following patch? diff --git a/t/t3203-instance-recovery.t b/t/t3203-instance-recovery.t
index 3ac63c61e..962de50f0 100755
--- a/t/t3203-instance-recovery.t
+++ b/t/t3203-instance-recovery.t
@@ -70,29 +70,32 @@ test_expect_success 'banner message warns changes are not persistent' '
grep "changes will not be preserved" banner2.out
'
test_expect_success 'recovery mode aborts early if statedir is missing' '
- test_must_fail flux start --recovery=$(pwd)/test2 2>dirmissing.err &&
+ test_must_fail flux start --recovery=$(pwd)/test2 true 2>dirmissing.err &&
grep "No such file or directory" dirmissing.err
'
test_expect_success 'recovery mode aborts early if statedir lacks rwx' '
mkdir -p test2 &&
chmod 600 test2 &&
- test_must_fail flux start --recovery=$(pwd)/test2 2>norwx.err &&
+ test_must_fail flux start --recovery=$(pwd)/test2 true 2>norwx.err &&
grep "no access" norwx.err
'
test_expect_success 'recovery mode aborts early if content is missing' '
chmod 700 test2 &&
- test_must_fail flux start --recovery=$(pwd)/test2 2>empty.err &&
+ test_must_fail flux start --recovery=$(pwd)/test2 true 2>empty.err &&
grep "No such file or directory" empty.err
'
-test_expect_success 'recovery mode aborts early if content unwritable' '
+# Check if read-only permissions work in this environment
+touch readonly && chmod 400 readonly
+printf test > readonly || test_set_prereq WORKING_PERMS
+test_expect_success WORKING_PERMS 'recovery mode aborts early if content unwritable' '
touch test2/content.sqlite &&
chmod 400 test2/content.sqlite &&
- test_must_fail flux start --recovery=$(pwd)/test2 2>nowrite.err &&
+ test_must_fail flux start --recovery=$(pwd)/test2 true 2>nowrite.err &&
grep "no write permission" nowrite.err
'
-test_expect_success 'recovery mode aborts early if content unreadable' '
+test_expect_success WORKING_PERMS 'recovery mode aborts early if content unreadable' '
chmod 200 test2/content.sqlite &&
- test_must_fail flux start --recovery=$(pwd)/test2 2>noread.err &&
+ test_must_fail flux start --recovery=$(pwd)/test2 true 2>noread.err &&
grep "no read permission" noread.err
' |
|
@grondo I'm still using fakeroot in my shell and made the above changes but see that the two tests that were failing are now being skipped. |
|
Yes, that means that This test is fixable via the kludge posted above, but who knows what else would break. I'd suggest not building or running |
|
@grondo Unfortunately, I am working in an environment where I do not have sudo privileges, and fakeroot is the only elevated privilege available to me. This restriction makes it challenging to follow the standard build and test process for Flux. Given this limitation, do you have any recommendations or alternative approaches that I could consider to build and test Flux within a Singularity container without sudo privileges? Any guidance or workarounds would be greatly appreciated. |
|
Yes. My suggestion is to use best practice for building software:
Of course, it is also possible to side install packages to a non-standard prefix. Many people use flux without having any kind of Perhaps singularity has requirements of which I'm not aware that are forcing you to use |
|
@grondo In my current environment, using Singularity, I am constrained by the system policies that limit my access to sudo privileges. As a result, I am exploring ways to work within these restrictions while still being able to build and test Flux. I appreciate your offer to propose changes that could help bypass this particular issue. If it's not too much trouble, I would be grateful for a PR that addresses this, as it would allow me to progress with my work. Additionally, if there are any other tips or workarounds for building and testing Flux within a Singularity container without sudo privileges, I'd like to hear them. |
|
Unfortunately, I've not used Singularity so I won't be helpful here. Calling @vsoch the expert! |
|
@mattf4171 you are wanting to run flux via a singularity container? That might be possible but it would be challenging. I would check out singularity compose and you will need to bind every single location that requires write, as singularity is a read only sif. You will also need to expose ports between "nodes" your workers. To step back, why do you want to do this? You are likely better off installing flux with conda in an environment. |
If you want to do a custom build of flux you need to use external CI (e.g., GitHub actions) and push to a registry and pull down to your system. And ensure that nothing is installed as root. |
Within
flux-core/t/t3203-instance-recovery.tfile,flux start --recovery=$(pwd)/test2command is succeeding even though thecontent.sqlitefile is set to read-only (chmod 400).test_expect_success 'recovery mode aborts early if content unwritable' ' mkdir -p test2 && pwd touch test2/content.sqlite && chmod 400 test2/content.sqlite && test_must_fail flux start --recovery=$(pwd)/test2 2>nowrite.err && grep "no write permission" nowrite.err 'Why is recovery mode not attempting to write to
content.sqlitefile?I ran the shell command outside of the test case for debugging purposes:
`
Environment:
Steps to Reproduce:
Expected Behavior:
Tests should run successfully, with the test_must_fail function correctly failing commands that are expected to fail.
Actual Behavior:
Tests that use test_must_fail fail with the error bash: test_must_fail: command not found.
Additional Information:
The .def file used for building the Singularity container includes the necessary dependencies and sets up the environment for Flux.
The issue persists even after ensuring proper permissions and environment variable settings.
The text was updated successfully, but these errors were encountered: