'specified instant was later than self' when installing rustlings on Windows Subsystem for Linux running Ubuntu 16.04

[asilano]

After installing the latest rust via rustup (--version reports 1.34.1), I followed the instructions at https://github.com/rust-lang/rustlings/ to get the rustlings tutorial running. The cargo install fails with:

crh54@UBPC-0406:/mnt/c/rustlings$ rustc --version
rustc 1.34.1 (fc50f328b 2019-04-24)

crh54@UBPC-0406:/mnt/c/rustlings$ RUST_BACKTRACE=1 cargo install --force --path .
  Installing rustlings v1.2.1 (/mnt/c/rustlings)
    Updating crates.io index
  Downloaded mio-extras v2.0.5
thread 'main' panicked at 'specified instant was later than self', src/libstd/sys/unix/time.rs:292:17
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:70
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:58
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::begin_panic
             at src/libstd/panicking.rs:412
   6: std::sys::unix::time::inner::Instant::sub_instant::{{closure}}
             at src/libstd/sys/unix/time.rs:292
   7: <std::time::Instant as core::ops::arith::Sub>::sub
             at /rustc/fc50f328b0353b285421b8ff5d4100966387a997/src/libcore/result.rs:764
             at src/libstd/sys/unix/time.rs:291
             at src/libstd/time.rs:215
             at src/libstd/time.rs:350
   8: cargo::core::package::Downloads::progress
   9: std::panicking::try::do_call
  10: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  11: curl::panic::catch
  12: curl::easy::handler::progress_cb
  13: Curl_pgrsUpdate
  14: Curl_readwrite
  15: multi_runsingle
  16: curl_multi_perform
  17: curl::multi::Multi::perform
  18: <std::thread::local::LocalKey<T>>::with
  19: cargo::core::package::Downloads::wait
  20: cargo::core::compiler::context::unit_dependencies::build_unit_dependencies
  21: cargo::core::compiler::context::Context::prepare_units
  22: cargo::core::compiler::context::Context::compile
  23: cargo::ops::cargo_compile::compile_ws
  24: cargo::ops::cargo_install::install_one
  25: cargo::ops::cargo_install::install
  26: cargo::commands::install::exec
  27: cargo::cli::main
  28: cargo::main
  29: std::rt::lang_start::{{closure}}
  30: std::panicking::try::do_call
             at src/libstd/rt.rs:49
             at src/libstd/panicking.rs:297
  31: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  32: std::rt::lang_start_internal
             at src/libstd/panicking.rs:276
             at src/libstd/panic.rs:388
             at src/libstd/rt.rs:48
  33: main
  34: __libc_start_main
  35: <unknown>
warning: spurious network error (2 tries remaining): [7] Couldn't connect to server
warning: spurious network error (1 tries remaining): [7] Couldn't connect to server
error: failed to compile `rustlings v1.2.1 (/mnt/c/rustlings)`, intermediate artifacts can be found at `/mnt/c/rustlings/target`

Caused by:
  failed to download from `https://crates.io/api/v1/crates/fnv/1.0.6/download`

Caused by:
  [7] Couldn't connect to server

It fails this way every time, although the "Downloaded" crate changes (it seems to manage to start the downloads, but fails quickly).

I'm not familiar with Rust's internals at all - let me know if I can generate more useful diags!

[Aaron1011]

The issue seems to be due to how 'non-monitonic clocks' are handled (as introduced by #56988)

Rust treats the Winodws system clock as potentially non-monotonic, in order to work around some weird system clock issues. However, since you're running Rust under WSL, you're running Rust built for Linux, which is treated as having a proper monotonic clock.

My guess is that WSL simply forwards gettimeofday to the underlying Windows clock, with all of the issues that entails.

[asilano]

That makes sense. Is there any way around this?

[Aaron1011]

Since WSL runs unmodified Linux binaries, I think Rust will need to do runtime detection of WSL

[kankri]

I decided to debug a Rust program which was not working correctly on Windows. Wanted to see the correct behavior on Linux first, so I tried to compile it with 1.33.0-x86_64-unknown-linux-gnu and got the same stack trace as above. I installed older toolchains one by one until 1.30.0-x86_64-unknown-linux-gnu finally was able to download the dependencies:

$ rustup update 1.30.0
$ rustup run 1.30.0 cargo install thecrate
...
this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["rename-dependency"]` to enable this feature

I think I'll wait for a better day to do Rust development.

[workingjubilee]

It is now useful to specify WSL1 vs WSL2. WSL1 uses the Windows APIs to fulfill Linux API calls. WSL2, as I understand it, directs such syscalls through a Linux kernel atop the Virtual Machine Platform. If this is a defect in WSL1, it is a known defect, and it is recommended to use WSL2 instead. In the light of that, I believe we can close this issue for now.

Of course, if I have missed something, then I would appreciate it if you reopened this with more information.