`statx` system call may return ENOSYS due to seccomp

[dtinth]

Related issue:

• Zig 0.14.0 fails to compile hello world on WSL 1 #23153

I’m not a Zig user, but I use Bun, which is built on top of Zig (and has recently upgraded to use Zig 0.14), to build applications that is packaged into a Docker image. However, in some environments it gets deployed to, the statx system call caused the application to crash when a file is read. Following is the strace line:

statx(12, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_TYPE|STATX_MODE|STATX_ATIME|STATX_MTIME|STATX_CTIME, 0x7fff8f276b30) = -1 ENOSYS (Function not implemented)

According to issue #23153, Zig requires kernel v4.19+. However, the environment in question is running on kernel version 6.1.0, yet we face the same issue.

This issue seems to be widespread in the Bun community:

• Unexpected reading oven-sh/bun#17629
• Cannot start docker TBosak/mkfd#14
• error: Unexpected reading oven-sh/bun#18823
• failure to build oven-sh/bun#18746
• Cannot Install Prisma on Bun Docker Image v1.2.3+ oven-sh/bun#18495
• With Docker : Error Unexpected reading "/app/src/index.tsx" C4illin/ConvertX#235
• v.1.2.2 is OK with Synology but not v.1.2.3 or 1.2.4 oven-sh/bun#18036

…when the application image is deployed into envionments where developers cannot control the kernel, such as:

• NAS devices stuck with an older kernel
• PaaS services running an older kernel
• Old servers running an old kernel

Our current workaround is to revert back to using an older version of Bun built on top of Zig 0.13, but that means we are stuck with an older Bun runtime for the time being. I reported this issue to the Bun project, and for the time being Bun team intends to patch Zig’s stdlib in their fork.

However, this issue may affect other non-Bun Zig users, so I am filing an issue here as well. It would also be great if we can arrive at a solution where Bun can use Zig without much patching on their side.

Alternatively, is there any way to disable the use of this system call?

[alexrp]

According to issue #23153, Zig requires kernel v4.19+. However, the environment in question is running on kernel version 6.1.0, yet we face the same issue.

Well, I don't know what to make of that. The syscall is clearly available since Linux 4.11: torvalds/linux@a528d35

Given your mention of Docker, my inclination is to suspect some issue there.

…when the application image is deployed into envionments where developers cannot control the kernel, such as:

In the linked issues, I see a couple of mentions of Linux 4.4. Since it has SLTS status, it's at least worth discussing whether that is a version Zig ought to support, however I would still note that 0d4d8df was included all the way back in Zig 0.12.0, so we've technically required Linux 4.19 for quite a while. Since @andrewrk authored that commit, I'll defer to him.

That said, I also see mention of Linux 3.10. It was released in 2013 and EOL'd in 2017, and isn't SLTS. I am not personally willing to write code for a kernel that old and unsupported.

[andrewrk]

For determining the minimum supported Linux kernel version, Zig tracks Debian LTS, which is currently bullseye at kernel version 5.10. So the 0.14.0 release should have been updated with Linux minimum version defaulting to 5.10.

[dtinth]

Some current environments I’m facing this issue with:

Synology NAS

The latest version of DSM (Synology’s Linux-based OS for the NAS) is 7.2.2-72806 Update 3 which is released in 2025-02-04.

The Linux kernel version is 4.4.302+ (which is still in SLTS).

Many people run their homelabs on a Synology NAS, which was infamous for using a very old kernel version (although they backport security patches). It features Container Manager which allows running Docker containers on it, so it’s one example of a popular in-market hardware that comes with a very outdated kernel.

OpenVZ-based hosts

The environment in which I run the Docker container was running inside OpenVZ-based host (Virtuozzo PaaS). So it’s something like this:

• Virtuozzo PaaS physical host. I don’t know which kernel is running on it.
  • Debian 12.9 VPS container, with uname -a reporting Linux 6.1.0.
    • Docker container
      • Bun

Since OpenVZ-based guests share the kernel as the physical host, it is quite possible but I’m not sure if it’s actually running on an older kernel, like Linux 3.10? which still receives patches.

---

Maybe a fallback can be implemented? e.g. if statx failed with ENOSYS, an alternative system call can be used instead?

[alexrp]

Many people run their homelabs on a Synology NAS, which was infamous for using a very old kernel version (although they backport security patches). It features Container Manager which allows running Docker containers on it, so it’s one example of a popular in-market hardware that comes with a very outdated kernel.

Can you update the kernel yourself on this hardware?

The environment in which I run the Docker container was running inside OpenVZ-based host (Virtuozzo PaaS). So it’s something like this:

What does uname -a inside the container say?

[dtinth]

Can you update the kernel yourself on this hardware?

No, this is unsupported. See Synology’s response on Reddit.

What does uname -a inside the container say?

Linux $hostname 6.1.0 #1 SMP Tue Jan 9 19:45:01 MSK 2024 x86_64 GNU/Linux

[alexrp]

Can you update the kernel yourself on this hardware?

No, this is unsupported. See Synology’s response on Reddit.

Do you mean unsupported as in "you literally can't do that" or "you can do it but Synology provides no support for it"?

What does uname -a inside the container say?

Linux $hostname 6.1.0 #1 SMP Tue Jan 9 19:45:01 MSK 2024 x86_64 GNU/Linux

At this point, I have to consider this to be a third-party issue. We're programming against a kernel interface introduced in Linux 4.11 and you're running Linux 6.1.0. The only possible explanation is interference from the container stuff.

What are your Docker and libseccomp versions in the Debian VPS?

[dtinth]

Do you mean unsupported as in "you literally can't do that" or "you can do it but Synology provides no support for it"?

There is a some community forum post on recompiling the kernel but it’s full of perils, and I don't think anyone will do that just to run a container on their NAS.

If I understand correctly, DSM uses a modified Linux kernel, and it is usually upgraded as part of a software update from Synology, so running a custom kernel will probably break the normal software update.

What are your Docker and libseccomp versions in the Debian VPS?

I installed Docker from https://get.docker.com/, so it should be a very recent version:

# docker version
Client: Docker Engine - Community
 Version:           28.0.2
 API version:       1.48
 Go version:        go1.23.7
 Git commit:        0442a73
 Built:             Wed Mar 19 14:36:58 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.0.2
  API version:      1.48 (minimum version 1.24)
  Go version:       go1.23.7
  Git commit:       bea4de2
  Built:            Wed Mar 19 14:36:58 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.26
  GitCommit:        753481ec61c7c8955a23d6ff7bc8e4daed455734
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

# apt show libseccomp2
Package: libseccomp2
Version: 2.5.4-1+deb12u1

[190n]

For determining the minimum supported Linux kernel version, Zig tracks Debian LTS

Is this intended as a minimum for the standard library, or for the language entirely? As far as I can tell, this was most recently changed in #17628, and the text description of that PR doesn't state it is specific to the standard library, but the version is written in a place that only mentions the standard library:

zig/lib/std/target.zig

Lines 237 to 238 in 0d4d8df

	/// The default `VersionRange` represents the range that the Zig Standard Library
	/// bases its abstractions on.

I do also see that the 0.13.0 release notes listed Linux 3.16+ as a Tier 1 target, even though the version in target.zig was already bumped to 4.19 by that point. Was that intended as the version that the compiler will support building programs for (without necessarily being able to use the standard library OS functions)?

[alexrp]

Is this intended as a minimum for the standard library, or for the language entirely?

Standard library and thus the compiler. You can still use the compiler on a supported kernel version to compile Zig code for older kernel versions, but you have to avoid the standard library OS abstractions.

I do also see that the 0.13.0 release notes listed Linux 3.16+ as a Tier 1 target

This was an accidental omission (since 0.12.0 in fact).

[190n]

Standard library and thus the compiler. You can still use the compiler on a supported kernel version to compile Zig code for older kernel versions, but you have to avoid the standard library OS abstractions.

I should've made it clearer that I was asking about building programs for old kernels, not running the compiler on old kernels. But that's good to hear, thanks.

[ericLemanissier]

As far as I know, all synology devices are running kernels <= 4.4 so they all are limited by this problem. Having zig resilient to the absence of statx would be a relief.

[lumenkeyes]

statx is also problematic on some versions of Android (between 9.0 and 11.0 afaict), where it is not included in the seccomp whitelist. Granted, those are still old kernels, but likely to be much more widely used than a Synology NAS.

[andrewrk]

I think if a given piece of software wants to pretend to be Linux 6.1.0, then it has to be compatible with Linux 6.1.0, and if any problems arise due to being incompatible, that's pretty obviously a bug in that software. For Zig to work around it would be irresponsible.

That goes for WSL too.

The Zig project is willing to go out of its way to support less popular operating systems, but if an OS claims to be Linux version X.Y.Z then it needs to be Linux version X.Y.Z.

The only way I could see this being worked around is if the target version is expanded to include sub-projects, i.e. zig's linux version would include a way to specify that it's actually targeting WSL, Synology, or zig's windows version is expanded to note that it's targeting a specific wine version, etc. However, I don't think that's a good idea because the whole point of those projects is compatibility with the OS they are pretending to be. So it's really not something that Zig should work around, it just makes everything shittier.

Please file a bug and send a patch to the software to fix statx.