32 位可执行文件不在 Docker 容器内休眠

Question

Windows 10 是主机系统。
Docker 桌面版 3.2.2（WSL2 集成）。
WSL2 Ubuntu 20.04。

#include <unistd.h>
int main() { sleep(1); return 0; }

用三种不同的方式编译代码：

gcc -o foobar-64 foobar.c
gcc -mx32 -o foobar-3264 foobar.c
gcc -m32 -o foobar-32 foobar.c

一切运行良好。 所有可执行文件都会休眠一秒钟。

现在在 Docker 中尝试相同的操作：

docker pull ubuntu:20.04
docker run --rm --interactive --tty ubuntu:20.04 bash
# then once inside: apt update && apt install build-essential g++-multilib

做同样的事。 只有前两个可执行文件正常休眠。 “纯 32 位可执行文件”没有。 它立即返回。

root@f24cf548c966:~# time ./foobar-64

real    0m1.002s
user    0m0.001s
sys     0m0.000s
root@f24cf548c966:~# time ./foobar-3264

real    0m1.003s
user    0m0.002s
sys     0m0.000s
root@f24cf548c966:~# time ./foobar-32

real    0m0.001s
user    0m0.001s
sys     0m0.000s

我没有运行 Linux 的 VM 来尝试一下它是否是 WSL2 的东西。

有什么线索吗？

[编辑]

所以我想在程序上尝试“strace”并揭示了一些有趣的东西......

容器外：

clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0xffd2f09c) = 0

容器内：

clock_nanosleep_time64(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0xffd2339c) = -1 EPERM (Operation not permitted)

在容器内部和外部，我都验证了可执行文件类型：

foobar-32: ELF 32-bit LSB shared object, Intel 80386, ...

Answer 1

显然这是一个 Docker 的东西。 EPERM 的事情引发了更多的搜索，我发现了这个

https://unix.stackexchange.com/questions/598471/docker-container-shows-sleep-cannot-read-realtime-clock-operation-not-permit

其中谈到了使用 --privileged 运行，它确实“解决”了问题，但该帖子中更有趣的链接是

https://github.com/moby/moby/commit/89fabf0f241292e929fbb2fbb794d58d8d697ab5

其中谈到了对默认 seccomp 的更新以添加 64 位 time_t 系统调用（其中之一是clock_nanosleep_time64 。

必须弄清楚如何在我的上下文中使用这些信息（AWS EKS 中的 AMI），但至少这不是什么新鲜事。