Weird Error on Cargo Install

Recently, I have faced with a very strange cargo behavior – it has refused to install some Rust utilities. For instance, when I tried to install the hyperfine tool using cargo, I got the following log:

$ cargo install hyperfine
Updating crates.io index
Installing hyperfine v1.11.0
Compiling libc v0.2.98
Compiling autocfg v1.0.1
Compiling proc-macro2 v1.0.28
Compiling rand_core v0.4.2
Compiling autocfg v0.1.7
Compiling unicode-xid v0.2.2
Compiling bitflags v1.2.1
Compiling syn v1.0.74
Compiling serde_derive v1.0.127
Compiling serde v1.0.127
Compiling memchr v2.4.0
Compiling getrandom v0.1.16
Compiling lazy_static v1.4.0
Compiling unicode-width v0.1.8
Compiling ryu v1.0.5
Compiling cfg-if v1.0.0
Compiling vec_map v0.8.2
Compiling ansi_term v0.11.0
Compiling regex-syntax v0.6.25
Compiling strsim v0.8.0
Compiling itoa v0.4.7
Compiling regex-automata v0.1.10
Compiling serde_json v1.0.66
Compiling ppv-lite86 v0.2.10
Compiling version_check v0.9.3
Compiling arrayvec v0.5.2
Compiling number_prefix v0.3.0
Compiling cfg-if v0.1.10
Compiling rand_core v0.3.1
Compiling rand_jitter v0.1.4
error: failed to run custom build command for `memchr v2.4.0`

Caused by:
could not execute process `/tmp/cargo-installGdVNP7/release/build/memchr-346b681ba8b82278/build-script-build` (never executed)

Caused by:
Permission denied (os error 13)
warning: build failed, waiting for other jobs to finish...
error: failed to compile `hyperfine v1.11.0`, intermediate artifacts can be found at `/tmp/cargo-installGdVNP7`

Caused by:
build failed

Obviously, having this error explanation (could not execute process - Permission denied (os error 13)) the first thing I checked was the file permissions using the ls -al command. However to my big surprise, the file has the execute bit set for all groups of users. I thought that, probably, after the last Rust update something has broken. To my surprise, in general cargo was working fine: I was able to create new projects, build and run them. After this, I understood that the journey of resolving this issue would be long.

I searched the Internet, however, the results were not very promising. While similar issues with the same keywords exist in the Internet, the provided solutions are very different. I have tried a number of them (e.g., reinstalling Rust from scratch, installing different build targets, various system compilers and other libraries), however, with no success.

The small number of such kind of issues in the Internet made me think that this error somehow related to my configuration, otherwise, there would be a large amount of similar questions. Therefore, I decided to think in this direction, and this decision brought me to the root cause of the problem.

So as my laptop has enough operating memory, in order to reduce the load on the solid state drive (SSD) I create a drive for temporary files (the /tmp directory )in RAM. This allows me to reduce the amount of SSD reads/writes, thus extending its healthiness. Moreover, during each reboot of the system, this drive is cleaned automatically.

In order to create the /tmp drive in memory, I have added the following entry to the /etc/fstab file (I have found this solution in the Internet long time ago):

tmpfs   /tmp   tmpfs   defaults,noatime,noexec,nosuid,nodev,mode=1777,size=2048M    0   0

The noexec flag, which is set for security reasons, prevents the execution of executable binaries in the mounted file system. Most of the time, everything in your system would be working fine with this flag set. However, when a binary needs to be executed from a drive mounted with this flag, you can get some strange errors. In order to resolve the issue, I have modified the entry in the fstab file in the following way:

tmpfs   /tmp   tmpfs   rw,noatime,nosuid,nodev,mode=1777,size=2048M   0   0

Unfortunately, for such kind of issues it is quite hard to identify the root cause, because the obvious first check with the ls command shows that the file has necessary permissions. For instance, after I have made this adjustment, another issue (the biber utility was not working on my system), has been resolved in my system. I am 99%-sure that the root cause is the same. The strace also proves this:

$ strace -f -e execve biber
execve("/home/yury/bin/biber", ["biber"], 0x7fffea0988c8 /* 66 vars */) = 0
strace: Process 22755 attached
[pid 22755] execve("/home/yury/.miktex/texmfs/install/biber/bin/linux-x86_64/biber", ["biber"], 0x555d14feac40 /* 76 vars */) = 0
[pid 22755] execve("/tmp/par-79757279/cache-231a862f2d3c7a47fd15d6f8b4436e4c4af18b72/biber", ["/tmp/par-79757279/cache-231a862f"...], 0xff12a0 /* 80 vars */) = 0
Usage:
biber [options] file[.bcf]
biber [options] --tool <datasource>

Creates "file.bbl" using control file "file.bcf" (".bcf" extension is
optional). Normally use with biblatex requires no options as they are
all set in biblatex and passed via the ".bcf" file

In "tool" mode (see B<--tool> option), takes a datasource (defaults to
"bibtex" datasource) and outputs a copy of the datasource with any command-line
or config file options applied.

Please run "biber --help" for option details

[pid 22755] +++ exited with 2 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22755, si_uid=1000, si_status=2, si_utime=79, si_stime=3} ---
+++ exited with 2 +++

For some reason biber executes a binary from the temporary directory:

[pid 22755] execve("/tmp/par-79757279/cache-231a862f2d3c7a47fd15d6f8b4436e4c4af18b72/biber", ["/tmp/par-79757279/cache-231a862f"...], 0xff12a0 /* 80 vars */) = 0

So as you can see, the errors related to this root cause may raise in completely unexpected locations. Therefore, I have decided to write this post in order to give one more angle to check if you face with similar issues.