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.

Sign up for GitHub

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

Jump to bottom

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

Open
mgorny opened this issue Sep 18, 2024 · 0 comments
Open

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

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

Comments

@mgorny
Copy link
Contributor

mgorny commented Sep 18, 2024 •
edited by bedevere-app bot
Loading

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
@bedevere-app bedevere-app bot mentioned this issue Sep 18, 2024
Open
gentoo-bot pushed a commit to gentoo/cpython that referenced this issue Sep 19, 2024
@mgorny
pythongh-124213: Skip tests failing with --suppress-sync=true whe…
5768235 
…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
@mgorny
pythongh-124213: Skip tests failing with --suppress-sync=true whe…
c5c6238 
…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
@mgorny
pythongh-124213: Skip tests failing with --suppress-sync=true whe…
6181713 
…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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@mgorny