Rustup: Panic: Failed to remove a dir: No such file or directory
Problem
I reached a state on a Linux machine where a simple rustup update fails. I only have one toolchain, the stable toolchain and rustup update stable works fine, but not rustup update.
$ RUST_BACKTRACE=1 rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: checking for self-updates
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.39.0 (4560ea788 2019-11-04)
info: cleaning up downloads & tmp directories
thread 'main' panicked at 'Failed to remove a dir: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/
libcore/result.rs:1165:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:76
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:60
4: core::fmt::write
at src/libcore/fmt/mod.rs:1030
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:64
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:196
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:473
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:380
12: rust_begin_unwind
at src/libstd/panicking.rs:307
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
14: core::result::unwrap_failed
at src/libcore/result.rs:1165
15: rustup_init::rustup_mode::update
16: rustup_init::rustup_mode::main
17: rustup_init::run_rustup_inner
18: rustup_init::main
19: std::rt::lang_start::{{closure}}
20: main
21: __libc_start_main
22: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Steps
I have no idea how to reach this state. But now I reproduce it with just rustup update.
Possible Solution(s)
Instead of just panicking, maybe print what directory it is expecting to exist? So it can be manually fixed maybe? I'm currently trying to figure out which directory it's talking about.
Notes
Output of rustup --version:
rustup 1.21.0 (fbf85f6fa 2019-12-18)
Output of rustup show:
Default host: x86_64-unknown-linux-gnu
rustup home: /home/build/.rustup
installed targets for active toolchain
--------------------------------------
aarch64-linux-android
armv7-linux-androideabi
i686-linux-android
x86_64-linux-android
x86_64-unknown-linux-gnu
active toolchain
----------------
stable-x86_64-unknown-linux-gnu (default)
rustc 1.39.0 (4560ea788 2019-11-04)
faern
All 10 comments
You beat me to it.
Problem
When running rustup update, the program panics when trying to clean a temporal directory that doesn't exist:
info: cleaning up downloads & tmp directories
thread 'main' panicked at 'Failed to remove a dir: Os { code: 2, kind: NotFound, message: "No such file or directory" }',
Steps
Unable to reproduce locally, but see https://travis-ci.com/witnet/witnet-rust/builds/141768995
Possible Solution(s)
Silent errors about removing non-existent files.
Notes
Output of rustup --version:
rustup 1.21.0 (fbf85f6fa 2019-12-18)
Output of rustup update:
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: checking for self-updates
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.39.0 (4560ea788 2019-11-04)
info: cleaning up downloads & tmp directories
thread 'main' panicked at 'Failed to remove a dir: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1165:5
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.37/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:76
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:60
4: core::fmt::write
at src/libcore/fmt/mod.rs:1030
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1412
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:64
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:196
9: std::panicking::default_hook
at src/libstd/panicking.rs:210
10: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:473
11: std::panicking::continue_panic_fmt
at src/libstd/panicking.rs:380
12: rust_begin_unwind
at src/libstd/panicking.rs:307
13: core::panicking::panic_fmt
at src/libcore/panicking.rs:85
14: core::result::unwrap_failed
at src/libcore/result.rs:1165
15: rustup_init::rustup_mode::update
16: rustup_init::rustup_mode::main
17: rustup_init::run_rustup_inner
18: rustup_init::main
19: std::rt::lang_start::{{closure}}
20: main
21: __libc_start_main
22: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
tmpolaczyk
on 19 Dec 2019
The panic certainly isn't good. I believe this is fairly easy to fix. The tmp directory isn't created until a download occurs I think.
kinnison
on 19 Dec 2019
This should be fairly easy to fix (and in the meantime, once a download actually occurs, it ought to be resolved)
kinnison
on 19 Dec 2019
Any simple way to work around this temporarily? I'd like to get the build server working if possible.
faern
on 19 Dec 2019
mkdir ~/.rustup/downloads I believe
kinnison
on 19 Dec 2019
Ok. Yeah that solves it for one single rustup update invocation. But good to know.
faern
on 19 Dec 2019
Oh ugh, yes, only once, this needs fixed now
kinnison
on 19 Dec 2019
Rolled back production to Rustup 1.20.2 while we wait for Rustup 1.21.1. Your next rustup update should downgrade to the old version.
pietroalbini
on 19 Dec 2019
@pietroalbini
On macOS, rustup doesn't manage itself, homebrew does. Since that project, unfortunately, has a reputation, a workaround is to reinstall rustup as follows:
(cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core && patch -Np1 && brew reinstall rustup-init) <<'PATCH'
--- a/Formula/rustup-init.rb 2019-12-26 19:30:38.000000000 -0800
+++ b/Formula/rustup-init.rb 2019-12-26 19:30:42.000000000 -0800
@@ -1,15 +1,8 @@
class RustupInit < Formula
desc "The Rust toolchain installer"
homepage "https://github.com/rust-lang/rustup.rs"
- url "https://github.com/rust-lang/rustup.rs/archive/1.21.0.tar.gz"
- sha256 "5dc7e1b16ec57c8cf9015f7f2b9780c09527b5f8783e8d5a62ddae7553a9587b"
-
- bottle do
- cellar :any_skip_relocation
- sha256 "dcfa31ebf56502047530a96d741e8d5a5631e25cff964d108963327fd2f31068" => :catalina
- sha256 "59a05d34a7ac1dd39d96698c46865c6c6113a5465aaa9e82bfe99ce0c7d45f4f" => :mojave
- sha256 "8c279d7a186437297b3cb28359392ed779561142e38c898d6a02a2370f1f6b3c" => :high_sierra
- end
+ url "https://github.com/rust-lang/rustup.rs/archive/1.20.2.tar.gz"
+ sha256 "28207ee4c2d66840ca903df152b23b916326a5d3eeb643a1de0f24a16afa4209"
depends_on "rust" => :build
PATCH
steakknife
on 27 Dec 2019
@steakknife by the way, we already got a point release fixing this issue the proper way, 1.21.1.
pietroalbini
on 27 Dec 2019
Related issues
mcandre
路
4Comments
fenhl
路
4Comments
matthiaskrgr
路
3Comments
Stargateur
路
3Comments
QuarkDoe
路
4Comments
Most helpful comment
mkdir ~/.rustup/downloadsI believe