Issue Description
The sandbox environment experiences intermittent, non-deterministic failures (e.g., "operation not permitted") during high-throughput or multi-threaded tasks, specifically when utilizing data science libraries like Pandas or Numpy. These crashes are caused by the sandbox's Seccomp filter blocking essential system calls (such as sched_getaffinity, pipe2, or statx) required by modern glibc under certain execution conditions.
Root Cause
The InitSeccomp function in internal/core/lib/python/add_seccomp.go manages the syscall whitelist. The current implementation relies on a static list that may not sufficiently cover the dynamic requirements of complex sub-processes or modern runtime libraries. Furthermore, if the ALLOWED_SYSCALLS configuration is improperly managed, it fails to provide the necessary flexibility for common runtime operations, leading to SIGSYS signals being triggered by the kernel, which silently terminates the sandbox process.
Impact：
-
Non-deterministic Runtime Errors: The sandbox crashes are difficult to reproduce, often only manifesting under heavy load or specific execution paths.
-
Evaluation Instability: For benchmarking or high-concurrency scheduling systems, these silent crashes lead to corrupted results, making evaluation metrics unreliable and unrepeatable.
Steps to Reproduce
-
Run a complex workload within the sandbox involving heavy computation or multi-threaded libraries (e.g., heavy Pandas/Numpy operations).
-
Execute the workload repeatedly under varying concurrency levels.
-
Observe intermittent process termination with "operation not permitted" errors, despite the logic being correct.
Expected Behavior
The sandbox should provide a stable execution environment that does not prematurely terminate legitimate processes required for standard scientific computations. The Seccomp configuration should be robust enough to support modern glibc dependencies or provide a clearer mechanism for extending the whitelist without risking system stability.
Additional Information
Operating System: Linux (Kernel Seccomp enabled)
Relevant Information: This issue appears to be related to the rigid definition of allowed system calls in python_syscall.ALLOW_SYSCALLS. Implementing a more granular or permissive profile for essential, non-privileged system calls may be necessary to resolve the instability.
Issue Description
The sandbox environment experiences intermittent, non-deterministic failures (e.g., "operation not permitted") during high-throughput or multi-threaded tasks, specifically when utilizing data science libraries like Pandas or Numpy. These crashes are caused by the sandbox's Seccomp filter blocking essential system calls (such as sched_getaffinity, pipe2, or statx) required by modern glibc under certain execution conditions.
Root Cause
The InitSeccomp function in internal/core/lib/python/add_seccomp.go manages the syscall whitelist. The current implementation relies on a static list that may not sufficiently cover the dynamic requirements of complex sub-processes or modern runtime libraries. Furthermore, if the ALLOWED_SYSCALLS configuration is improperly managed, it fails to provide the necessary flexibility for common runtime operations, leading to SIGSYS signals being triggered by the kernel, which silently terminates the sandbox process.
Impact：
Non-deterministic Runtime Errors: The sandbox crashes are difficult to reproduce, often only manifesting under heavy load or specific execution paths.
Evaluation Instability: For benchmarking or high-concurrency scheduling systems, these silent crashes lead to corrupted results, making evaluation metrics unreliable and unrepeatable.
Steps to Reproduce
Run a complex workload within the sandbox involving heavy computation or multi-threaded libraries (e.g., heavy Pandas/Numpy operations).
Execute the workload repeatedly under varying concurrency levels.
Observe intermittent process termination with "operation not permitted" errors, despite the logic being correct.
Expected Behavior
The sandbox should provide a stable execution environment that does not prematurely terminate legitimate processes required for standard scientific computations. The Seccomp configuration should be robust enough to support modern glibc dependencies or provide a clearer mechanism for extending the whitelist without risking system stability.
Additional Information
Operating System: Linux (Kernel Seccomp enabled)
Relevant Information: This issue appears to be related to the rigid definition of allowed system calls in python_syscall.ALLOW_SYSCALLS. Implementing a more granular or permissive profile for essential, non-privileged system calls may be necessary to resolve the instability.