Change:
flags: i32, mask: u32, ) -> Option<io::Result<FileAttr>> { <del> use crate::sync::atomic::{AtomicBool, Ordering}; </del> <ins> use crate::sync::atomic::{AtomicU8, Ordering}; </ins> // Linux kernel prior to 4.11 or glibc prior to glibc 2.28 don't support `statx` <del> // We store the availability in a global to avoid unnecessary syscalls static HAS_STATX: AtomicBool = AtomicBool::new(true); </del> <ins> // We store the availability in global to avoid unnecessary syscalls. // 0: Unknown // 1: Not available // 2: Available static STATX_STATE: AtomicU8 = AtomicU8::new(0); </ins> syscall! { fn statx( fd: c_int,

Discussion:
When I run this sequence of commands: I get this error: This happens due to the failing with EPERM. I believe Docker uses seccomp to limit which system calls may be made, and the call is too new, so it's . Because the syscall fails with EPERM instead of ENOSYS, the fallback to regular doesn't work. Host kernel: 4.15.0-65-generic docker version
Nominating for libs team as this is a recent regression caused by -- cc Personally this leads me to believe we should either be happier to fallback to the previous code (e.g., for any error) or revert the PR entirely since breaking usage of Rust code in Docker is not really feasible (even if this is arguably a Docker bug).
Alternatively, we can try statx on something that should always succeed (maybe ?)
Cannot it match ENOSYS or EPERM just like getrandom syscall does?
Unlike for , getting EPERM is not sufficient evidence that doesn't work.
Thanks for investigating this down to being the culprit, definitely makes sense! I was searching around for other instances of this, and definitely turns out we're not the only ones running into this - another docker user reporting the same issue. It's pointed out that Docker 18.04 apparently allows by default - another user with qt's build system finding that seccomp disallows a new syscall Looks like musl (called ) and only handles ENOSYS Seccomp itself got support for statx as a sycall in general Overaall I don't think there's a lot of prior art for this to draw from, it seems that everyone's working around the seccomp issue rather than addressing it directly. I think a reasonable solution might be to do something like try to stat initially and if that fails with EPERM or ENOSYS we disable the syscall entirely, otherwise it's cached as always good to use. would you be interested in helping to implement this?
Do you mean to check current working directory instead of the actual argument before the first call, and regard EPERM and ENOSYS as not implemented? I'm glad to fix it.

yeah that's what I'm thinking, the idea being that if we don't know whether works we invoke it with a path which we know should work almost all the time (like the cwd) and if it returns EPERM in that situation we can be pretty certain we're seccomp blocked.
We are encountering a similar issue while building an Docker image with rustc & cargo on CircleCI. We are basically doing: and are getting: This errors happens since yesterday. Our last successful build with the same script was 2 days ago, with these versions: So basically between and , something changed that makes unable to figure out that is installed. After many tests on different Docker hosts, we haved narrowed the issue to the following: if the Docker host is using the or storage drivers, everything works perfectly; if it is using storage driver, then basically cannot see that the file exists, and treats rustfmt as not installed.
On the hosts where things don't work, what is the docker version and host kernel version? Also, can you run your command with to see if this is because of ?
I tried with docker 18.09.2 on Linux kernel 4.14.118, it seems that works well. Maybe need to update docker?
Related?
You need rather recent Docker and libseccomp packges. Old Docker versions (or new versions running on the old systems) default to aufs but in recent versions this has changed to overlay2. That's possible explanation of what you are seeing.
On CircleCI you cannot choose the storage driver, though you can opt in to newer Docker versions, which we've done. on CircleCI Kernel and Docker versions are fairly recent, but aufs is indeed being used. I also tried 's snippet on a standard image which produced the following output: Now, CircleCI may or may not be doing something unorthodox here, but I think it is clear that this change has broken things for potentially quite a few users who do not have the capability to simply update or reconfigure their docker environment by themselves.
can you confirm your issue was solved with the latest nightly?
I can confirm it seems to work well in docker again :+1: We were having these issues with last week, and to docker to solve it. Now we can remove it and it still works.
Yes, it's working perfectly again! Thank you!