Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failures inside systemd-nspawn --suppress-sync=true container #124213

Closed
mgorny opened this issue Sep 18, 2024 · 1 comment
Closed

Test failures inside systemd-nspawn --suppress-sync=true container #124213

mgorny opened this issue Sep 18, 2024 · 1 comment
Labels
type-bug An unexpected behavior, bug, or error

Comments

@mgorny
Copy link
Contributor

mgorny commented Sep 18, 2024

Bug report

Bug description:

When the CPython's test suite is run inside a systemd-nspawn container with --suppress-sync=true specified, the following tests fail:

======================================================================
FAIL: test_fdatasync (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.8.19_p2/work/Python-3.8.19/Lib/test/test_os.py", line 1850, in helper
    self.check(getattr(os, f))
  File "/var/tmp/portage/dev-lang/python-3.8.19_p2/work/Python-3.8.19/Lib/test/test_os.py", line 1861, in check
    self.fail("%r didn't raise an OSError with a bad file descriptor"
AssertionError: <built-in function fdatasync> didn't raise an OSError with a bad file descriptor

======================================================================
FAIL: test_fsync (test.test_os.TestInvalidFD)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.8.19_p2/work/Python-3.8.19/Lib/test/test_os.py", line 1850, in helper
    self.check(getattr(os, f))
  File "/var/tmp/portage/dev-lang/python-3.8.19_p2/work/Python-3.8.19/Lib/test/test_os.py", line 1861, in check
    self.fail("%r didn't raise an OSError with a bad file descriptor"
AssertionError: <built-in function fsync> didn't raise an OSError with a bad file descriptor

----------------------------------------------------------------------
======================================================================
FAIL: test_flush_return_value (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/python-3.8.19_p2/work/Python-3.8.19/Lib/test/test_mmap.py", line 746, in test_flush_return_value
    self.assertRaises(OSError, mm.flush, 1, len(b'python'))
AssertionError: OSError not raised by flush

----------------------------------------------------------------------

This is because systemd-nspawn uses seccomp to stub out fsync(), fdatasync() and msync() calls, and this implies they always return success.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

@mgorny mgorny added the type-bug An unexpected behavior, bug, or error label Sep 18, 2024
gentoo-bot pushed a commit to gentoo/cpython that referenced this issue Sep 19, 2024
…n inside systemd-nspawn container

Add a helper functon that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Technically, this means that the tests are also skipped when running
inside systemd-nspawn container without `--suppress-sync=true`.
However, to the best of my knowledge the only way to detect this option
is to actually reproduce one of the unexpectedly-succeeding syscalls,
and since this is precisely what we're testing for, the skip-test
and the actual test would be doing the same thing.

Signed-off-by: Michał Górny <[email protected]>
gentoo-bot pushed a commit to gentoo/cpython that referenced this issue Sep 19, 2024
…n inside systemd-nspawn container

Add a helper functon that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Technically, this means that the tests are also skipped when running
inside systemd-nspawn container without `--suppress-sync=true`.
However, to the best of my knowledge the only way to detect this option
is to actually reproduce one of the unexpectedly-succeeding syscalls,
and since this is precisely what we're testing for, the skip-test
and the actual test would be doing the same thing.

Signed-off-by: Michał Górny <[email protected]>
gentoo-bot pushed a commit to gentoo/cpython that referenced this issue Sep 19, 2024
…n inside systemd-nspawn container

Add a helper functon that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Technically, this means that the tests are also skipped when running
inside systemd-nspawn container without `--suppress-sync=true`.
However, to the best of my knowledge the only way to detect this option
is to actually reproduce one of the unexpectedly-succeeding syscalls,
and since this is precisely what we're testing for, the skip-test
and the actual test would be doing the same thing.

Signed-off-by: Michał Górny <[email protected]>
vstinner pushed a commit that referenced this issue Sep 20, 2024
…rue (#124215)

Add a helper function that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Call `os.open(__file__, os.O_RDONLY | os.O_SYNC)` and check the errno to
detect whether `--suppress-sync=true` is actually used, and skip
the tests only in that scenario.
@vstinner
Copy link
Member

Fixed by change 342e654.

savannahostrowski pushed a commit to savannahostrowski/cpython that referenced this issue Sep 22, 2024
…sync=true (python#124215)

Add a helper function that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Call `os.open(__file__, os.O_RDONLY | os.O_SYNC)` and check the errno to
detect whether `--suppress-sync=true` is actually used, and skip
the tests only in that scenario.
savannahostrowski pushed a commit to savannahostrowski/cpython that referenced this issue Sep 22, 2024
…sync=true (python#124215)

Add a helper function that checks whether the test suite is running
inside a systemd-nspawn container, and skip the few tests failing
with `--suppress-sync=true` in that case.  The tests are failing because
`--suppress-sync=true` stubs out `fsync()`, `fdatasync()` and `msync()`
calls, and therefore they always return success without checking for
invalid arguments.

Call `os.open(__file__, os.O_RDONLY | os.O_SYNC)` and check the errno to
detect whether `--suppress-sync=true` is actually used, and skip
the tests only in that scenario.
mgorny added a commit to mgorny/cpython that referenced this issue Oct 2, 2024
…wn_sync_suppressed()

Fix the incorrect use of `os.open()` result as a context manager,
while it is actually a numeric file descriptor.

I have missed the problem, because in the original version the
`os.open()` call would always fail, and I failed to test the final
version in all possible scenarios properly.
vstinner pushed a commit that referenced this issue Oct 2, 2024
…c_suppressed() (#124892)

Fix the incorrect use of `os.open()` result as a context manager,
while it is actually a numeric file descriptor.

I have missed the problem, because in the original version the
`os.open()` call would always fail, and I failed to test the final
version in all possible scenarios properly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants