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

Large quantities of stderr from exec() not always fully captured #23

Open
craigwalton-dsit opened this issue Dec 19, 2024 · 0 comments
Open
Labels
bug Something isn't working

Comments

@craigwalton-dsit
Copy link
Collaborator

craigwalton-dsit commented Dec 19, 2024

The following test is a bit savage, but reliably reproduces the issue.

async def test_exec_reliability_stderr(
    sandbox_non_root: K8sSandboxEnvironment,
) -> None:
    head_limit = 1024 * 100  # 100 KiB
    cmd = ["sh", "-c", f"yes | head -c {head_limit} 1>&2"]

    for _ in range(10):
        awaitables = [sandbox_non_root.exec(cmd) for _ in range(100)]

        for result in await asyncio.gather(*awaitables):
            assert result.success
            assert len(result.stderr) == head_limit

Note the use of sandbox_non_root which is ubuntu without gVisor. This seems to repro the issue much more readily than the default sandbox with gVisor.

Hypothesis: WSClient is closed by us when we read the sentinel value, but not all of stderr has been sent over the websocket. It seemed that adding the sync command to the sh script improved this, but didn't make it 100% reliable.

When we don't manually close the websocket upon reading the sentinel value, this test passes.

@craigwalton-dsit craigwalton-dsit added the bug Something isn't working label Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant