New parallel download + install can easily leave a partially installed toolchain when downloads are interrupted

[steffahn]

I haven’t yet checked if current rustup produces a similar state when aborted during the extraction phase of an install, but in any case, it’s going to be much more common that someone manually interrupts the process during the download phase, because downloads can get stuck and timeouts are slow.

What I did:

$ rustup --version
rustup 1.29.0 :: 1.28.2+486 (732af7663 2026-02-02)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.93.1 (01f6ddf75 2026-02-11)`

$ rustup toolchain install nightly-2026-01-01
info: syncing channel updates for nightly-2026-01-01-x86_64-unknown-linux-gnu
info: latest update on 2026-01-01 for version 1.94.0-nightly (8d670b93d 2025-12-31)
info: downloading 6 components
        cargo installed                       10.36 MiB
       clippy installed                        4.41 MiB
    rust-docs downloading [######         ]   20.58 MiB (304.31 KiB/s, ETA: 44s)
     rust-std downloading [#              ]   28.29 MiB (208.89 KiB/s, ETA: 2m)
^C

(interrupted via ctrl+c while cargo & clippy was already installed, and the next ones were in the middle of downloading)

then:

$ cargo +nightly-2026-01-01 --version 
cargo 1.94.0-nightly (b54051b15 2025-12-30)

$ rustc +nightly-2026-01-01 --version
error: Missing manifest in toolchain 'nightly-2026-01-01-x86_64-unknown-linux-gnu'

$ cargo +nightly-2026-01-01 clippy --version
/home/frank/.rustup/toolchains/nightly-2026-01-01-x86_64-unknown-linux-gnu/bin/cargo-clippy: error while loading shared libraries: librustc_driver-bcf6c5c396c0890f.so: cannot open shared object file: No such file or directory

I think this is an undesirable state to leave someone’s install in. Additionally, if re-tried now, it produces a lot of extra warnings:

$ rustup toolchain install nightly-2026-01-01
info: syncing channel updates for nightly-2026-01-01-x86_64-unknown-linux-gnu
info: latest update on 2026-01-01 for version 1.94.0-nightly (8d670b93d 2025-12-31)
info: removing previous version of component rustc
warn: component rustc not found during uninstall
info: removing previous version of component cargo
warn: component cargo not found during uninstall
info: removing previous version of component rust-std
warn: component rust-std not found during uninstall
info: removing previous version of component rust-docs
warn: component rust-docs not found during uninstall
info: removing previous version of component rustfmt
warn: component rustfmt not found during uninstall
info: removing previous version of component clippy
warn: component clippy not found during uninstall
info: downloading 6 components
        rustc installed                       74.58 MiB
        cargo installed                       10.36 MiB
     rust-std installed                       28.29 MiB
    rust-docs installed                       20.58 MiB
      rustfmt installed                        2.08 MiB
       clippy installed                        4.41 MiB                                                                 
  nightly-2026-01-01-x86_64-unknown-linux-gnu installed - rustc 1.94.0-nightly (8d670b93d 2025-12-31)

(at least in the end the whole thing seems to be in a proper/clean state again now)

[rami3l]

TLDR: Before we had the download phase and the extraction phase executed serially. The download phase can be interrupted and picked up freely, while the extraction phase will retry the whole thing on interruption. Now since we interleave the two, both will be triggered at the same time when you hit ^c, and the latter will be observed more often (the downloads will be resumed normally if I'm not mistaken).
#4560 (comment)

Essentially this is the same if you hit ^c in older versions of rustup when the extraction is being executed.

[rami3l]

I think this is an undesirable state to leave someone’s install in.

You are right about this point, and my proposal has it covered. All kinds of feedback is welcome! :)

[steffahn]

@rami3l For context, is this proposal something that’s planned to still be included with the upcoming release?

Otherwise, it might be worth additionally discussion what simpler mitigations could perhaps help to at least make the situation not become worse with the upcoming release (“become worse” since, as mentioned, it’s much more likely someone cancels a download than someone cancelling the downloads (especially if slow or stuck) than an “all is downloaded, we’re now just actually extracting/installing” process).

[rami3l]

@steffahn Changing the transaction mechanism is not something we can deliver in the upcoming release, unfortunately.

On the other hand it should be possible to introduce an option to just not extract the file until all downloading is finished (at the cost of a few seconds of extracting overhead). It really depends on how optimistic you are with your network environment.

However I'd argue if the above is necessary. I think in the end it's just some extra FS operations and some extra logs compared to the older versions, the downloads as they should be are perfectly resumable and you are resuming them just like before (so few things are getting any worse IMHO).

I do think the logs are probably a bit too noisy for my taste though: it might look like something bad happening but it isn't! Quite the contrary actually: rustup is trying to recover from an interruption.

What do you think, @FranciscoTGouveia?

[rami3l]

@steffahn Aside: we are trying our best to make this stranded project sailing again, and for the moment being we are still struggling as a team of 3 volunteers. I'd greatly appreciate your understanding for us not being as responsive as you'd typically expect and we could really use your help, be it technical suggestions, code contributions (as you have done previously) or any relevant support. Many thanks in advance 🙏

[steffahn]

@rami3l no criticism intended at all. I was in fact looking at this issue myself when discovering it, and wondered my own ideas on potential mitigations (I just asked to make sure if discussing those wouldn’t be redundant).

As far as I remember from looking at the code 2 weeks ago, a I noticed that the extraction process seems to be a 2 step thing, first doing extraction some place and only in the end moving it into the final destination; and thus I wondered what would happen if only that second step was delayed (which should usually be almost instant anyway) and also only that second part was inside of some "transaction" if I recall correctly.

Unless this sounds like a thing that cannot possibly work well for some fundamental reason, I might just go ahead and try out and see what happens if rewriting the code so that all the "moving into place" operations are bundled towards the end. I’ll be back home from London on Saturday, so likely nothing will happen before that.

[rami3l]

all the "moving into place" operations are bundled towards the end

@steffahn That's also what has been discussed in my proposal, although I'm not sure how you would bundle those operations without changing the transaction to be actually moving an assembled folder from one place to another.

In your particular case rustup is installing a new toolchain so that can be special-cased, but when modifying an existing toolchain it won't be so easy. But in the end a fix is a fix, I guess!

[steffahn]

In your particular case rustup is installing a new toolchain so that can be special-cased, but when modifying an existing toolchain it won't be so easy. But in the end a fix is a fix, I guess!

Thanks for the pointer, I’ll keep in mind to test the behavior for both cases!

[steffahn]

On that note, it’s kind-of challenging to manually test updates, because if you install something it’s already the latest version, and it’s not like there’s versions being updated all the time. @rami3l do you happen to have any recommedations on how to manually test this?
(Ah… I guess what I could do is just store my whole .rustup – or relevant parts – before doing a nightly update, and then that’s a repeatible case.)

---

Edit: I kinda want some RUSTUP_DIST_SERVER that serves outdated versions of stuff for testing purposes xD

Edit2: On second thought, I guess making a local mirror that does exactly that maybe isn’t actually any complicated 🤔

[rami3l]

do you happen to have any recommedations on how to manually test this?

@steffahn Ha! I believe I and @FranciscoTGouveia have considered both options you've mentioned when implementing the "concurrent rustup" proposal. I'm not quite sure what he ended up using though 👀

We have a pretty comprehensive mock release server thing in src/test/dist but so far it's only for in-house E2E tests.

---

Update: Better yet, for your case since you don't need to do any network-related work, actually we accept file:// links as RUSTUP_DIST_SERVER, if that makes your life a bit easier.

[FranciscoTGouveia]

Although leaving an installation in an inconsistent state is, of course, not desirable, it is important to emphasize that this already occurred before the introduction of concurrent downloads, just on a smaller scale, since installations were all performed at the end.

I would argue that moving the installation step to run only after all downloads have completed would introduce a considerable overhead, almost cancelling the performance improvements introduced in 1.29.
That said, a possible approach could be to introduce a new flag that makes this behavior configurable for users who need it.

Additionally, I agree that the logs produced after retrying the installation are somewhat excessive.
They could likely be replaced with a more concise and informative message.
If this sounds reasonable, I would be happy to look into preparing a patch over the next few days.