'rustc' panicked at 'failed to acquire jobserver token: ...' #46981
Comments
|
I experienced this error now multiple times. Maybe it is a good idea to include the complete build output here: |
|
With |
|
For the record: |
|
For whatever reason, this is making it effectively impossible for me to package projects with lots of dependencies for Nix. |
pietroalbini
added
I-ICE
|
I can reliably hit this bug when compiling my project (https://github.com/bennofs/nix-index) with Nix |
|
I believe this is a bug in our rustc package in nixpkgs, we appear to build it against |
|
There is an issue here: rustc version 1.22.1 has @alexcrichton you are the author of |
|
@bennofs the workaround would be to remove any ambient jobservers and let cargo/rustc manage it, if any |
|
Can't we bootstrap using 1.23.0 binaries? |
|
I can reliably hit this bug as well in nix |
Bump the Rust toolchain version specified in `shell.nix` from 1.22.1 to 1.24.1 to escape a `jobserver` bug: <rust-lang/rust#46981>. Version 1.24.1 comes with rustfmt, so this patch also drops the dependency on the Nix package for rustfmt. The version of rustfmt bundled with rustc 1.24.1 does not accept any of the `rustfmt.toml` configuration file options I was using, so this patch deletes `rustfmt.toml`.
Update my Rust toolchain installation from version 1.22.1 to version 1.24.1 to escape a jobserver bug: <rust-lang/rust#46981>. Version 1.24.1 comes with rustfmt, so this patch uninstalls the Nix package for rustfmt.
|
I can reliably hit this bug using As far as I am aware I don't have any jobservers running. |
|
I realized that the following issue was only occurring on nightly. However after the latest update this is now occurring on stable as well. % cargo version
cargo 1.33.0 (f099fe94b 2019-02-12)
% rustc --version
rustc 1.33.0 (2aa4c46cf 2019-02-28) |
|
still persists using |
|
@alexcrichton Can you please take another look at this. It appears that your diagnosis is wrong and many people are experiencing this issue. There is no workaround as far as I can tell and this is seriously workflow disrupting. |
|
A misconfigured jobserver can still cause issues in rustc, and this error is indicative of a misconfigured jobserver in one way or another. This indicates an environmental problem rather than a problem in rustc AFAIK. If someone else manages to fix rustc we can of course merge, but I don't personally believe there's much we can do in rustc for this. |
|
There is no other jobserver in my environment. I have checked numerous ways and am highly confident. |
|
@alexcrichton I am also getting the same error as @kevincox when running entr with the reload flag. find . -name "*.rs" | entr -rs 'cargo run'Throws the following error: error: failed to acquire jobserver token: early EOF on jobserver pipeAccording to the entr documentation whats happening is :
|
|
I created an upstream issue for https://bitbucket.org/eradman/entr/issues/81/restart_ops-closing-of-stdin-causes |
|
It sounds like the underlying issue is #60447 |
|
A workaround for those using find Cargo.* src/ static/ ... -type f | entr -r sh -c 'cargo run < /dev/null'It works for me with |
|
This is no longer happening for me. I don't know what has changed but I don't see this anymore. |
|
It still happens for me with |
|
So, I've found an entirely legitimate way to trigger this error (the "early EOF on jobserver pipe" case) on new versions of If you call # Assume we are using `cmake`
add_custom_target(
...
COMMAND cargo build
...
)then Except that new versions of The solution is to prevent # Assume we are using `cmake`
add_custom_target(
...
COMMAND SNEAK_DOLLAR_MAKE_INTO_THE_COMMAND=$(MAKE) cargo build
...
)This is silly, but it seems like |
Reopen standard file descriptors when they are missing on Unix
The syscalls returning a new file descriptors generally return lowest-numbered
file descriptor not currently opened, without any exceptions for those
corresponding to stdin, sdout, or stderr.
Previously when any of standard file descriptors has been closed before starting
the application, operations on std::io::{stderr,stdin,stdout} were likely to
either succeed while being performed on unrelated file descriptor, or fail with
EBADF which is silently ignored.
Avoid the issue by using /dev/null as a replacement when the standard file
descriptors are missing.
The implementation is based on the one found in musl. It was selected among a
few others on the basis of the lowest overhead in the case when all descriptors
are already present (measured on GNU/Linux).
Closes rust-lang#57728.
Closes rust-lang#46981.
Closes rust-lang#60447.
Benefits:
* Makes applications robust in the absence of standard file descriptors.
* Upholds IntoRawFd / FromRawFd safety contract (which was broken previously).
Drawbacks:
* Additional syscall during startup.
* The standard descriptors might have been closed intentionally.
* Requires /dev/null.
Alternatives:
* Check if stdin, stdout, stderr are opened and provide no-op substitutes in std::io::{stdin,stdout,stderr} without reopening them directly.
* Leave the status quo, expect robust applications to reopen them manually.
… r=bjorn3 do not panic on failure to acquire jobserver token Purpose: remove `panic`. Rust fails to acquire token if an error in build system occurs - environment variable contains incorrect `jobserver-auth`. It isn't ice so compiler shouldn't panic on such error. Related issue: rust-lang#46981
|
was recently facing similar issue while trying to run cargo build inside a makefile with buildroot This worked for me. |
|
If you are actually running cargo inside of make you are hitting a different problem and I recommend opening a different issue. This issue was about a bug where no job server was running. This issue was fixed. |
This seems to be related to #42867, though not entirely the same.
I am in the process of
cargo publishing my crate (multiple crates in a workspace project) imag v0.5.0 (from this commit).Instead of a normal compile process, I got this:
rustc --version --verbose:The text was updated successfully, but these errors were encountered: