Failure to run on Ubuntu 20.04 LTS

[whb07]

Issue

Following the example on the homepage the build fails to run. This also happened on my local ubuntu 20 machine. This issue seen as well when running one of the examples.

machine

On a brand new, freshly spun up VM for this very bug report:

root@ubuntu-s-4vcpu-8gb-amd-sfo3-01:~/hello-rocket# rustup default stable
info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.52.1 (9bc8c42bb 2021-05-09)

root@ubuntu-s-4vcpu-8gb-amd-sfo3-01:~/hello-rocket# lsb_release -a 
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

error

root@ubuntu-s-4vcpu-8gb-amd-sfo3-01:~/hello-rocket# RUST_BACKTRACE=full cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.11s     
Running `target/debug/hello-rocket`thread 'main' panicked at 'create tokio runtime: Os 
{ code: 22, kind: InvalidInput, message: "Invalid argument" }', 
/root/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.5.0-rc.1/src/lib.rs:232:10stack backtrace:
...

rest of trace

[Kafva]

I have the same issue when trying to run the hello-world example on macOS and Arch

[SergioBenitez]

This error is arising due to a failure to initialize the tokio runtime. Given we do nothing non-standard here, this is either a bug in tokio or some undocumented compatibility wart. All of our Linux CI machines run on Ubuntu 20.04, so it appears that something in your setup specifically is triggering this.

Unfortunately the backtrace is not particularly helpful as it says nothing about where the error arose. This is a known issue with errors in Rust. There's an accepted RFC which aims to resolve this issue by attaching a backtrace to the error. The RFC has been implemented in nightly. It would be ideal if you could:

1. Clone the repository into the VM where the issue is occuring.
2. cd examples/hello && cargo run, ensuring things still fail
3. rustup default nightly (check rustc --version for nightly)
4. cd examples/hello && cargo run, ensuring things still fail
5. apply the patch below
6. run your example again with RUST_BACKTRACE=1, which should give you an error backtrace

diff --git a/core/lib/src/lib.rs b/core/lib/src/lib.rs
index 185babe0..d9320bb6 100644
--- a/core/lib/src/lib.rs
+++ b/core/lib/src/lib.rs
@@ -5,6 +5,7 @@
 #![doc(html_logo_url = "https://rocket.rs/images/logo-boxed.png")]
 #![cfg_attr(nightly, feature(doc_cfg))]
 #![cfg_attr(nightly, feature(decl_macro))]
+#![cfg_attr(nightly, feature(backtrace))]
 
 #![warn(rust_2018_idioms)]
 #![warn(missing_docs)]
@@ -223,12 +224,26 @@ pub fn async_main<R>(fut: impl std::future::Future<Output = R> + Send) -> R {
     // FIXME: The `workers` value won't reflect swaps of `Rocket` in attach
     // fairings with different config values, or values from non-Rocket configs.
     // See tokio-rs/tokio#3329 for a necessary solution in `tokio`.
-    tokio::runtime::Builder::new_multi_thread()
+    let result = tokio::runtime::Builder::new_multi_thread()
         .worker_threads(Config::from(Config::figment()).workers)
         // NOTE: graceful shutdown depends on the "rocket-worker" prefix.
         .thread_name("rocket-worker-thread")
         .enable_all()
-        .build()
-        .expect("create tokio runtime")
-        .block_on(fut)
+        .build();
+
+    match result {
+        Ok(runtime) => runtime.block_on(fut),
+        #[cfg(nightly)]
+        Err(e) => {
+            use std::error::Error;
+
+            if let Some(backtrace) = e.backtrace() {
+                eprintln!("tokio runtime error backtrace: {}", backtrace);
+            }
+
+            panic!("tokio runtime failed to initialize: {}", e);
+        }
+        #[cfg(not(nightly))]
+        Err(e) => panic!("tokio runtime failed to initialize: {}", e),
+    }
 }

[whb07]

Thanks for the quick response. Now let me clarify this:

my home desktop running Ubuntu 20, x86-64 ran across the same issue.

a brand new, VM from DO got spun up for this bug report running Ubuntu 20.04/x86-64 also ran across the issue.

Perhaps it’s something in your environment that’s not being pulled down or declared for the other systems to refer to ?

[whb07]

I’ve got a light Saturday tonight, I’ll report back on a different cloud provider’s Ubuntu 20.04.

[Azgrom]

Hey there! I am having this same issue. But I cannot reproduce the error when I follow those steps. Both in stabe and nightly compilers.

1. Clone the repository into the VM where the issue is occuring.

2. `cd examples/hello && cargo run`, ensuring things still fail

3. `rustup default nightly` (check `rustc --version` for `nightly`)

4. `cd examples/hello && cargo run`, ensuring things _still_ fail

5. apply the patch below

6. run your example again with `RUST_BACKTRACE=1`, which should give you an error backtrace

What I do to reproduce this error:

1. $ cargo new --bin rocket_example
2. Add rocket as dependency in Cargo.toml

[dependencies]
rocket = "0.5.0-rc.1"

3. Replace this 'pastebin' snippet to main.rs content:

#[macro_use] extern crate rocket;

#[launch]
fn rocket() -> _ {
    rocket::build()
}

4. Run cargo run either with stable or nightly compilers. After it compiles 171 packages the executable panics the following error:

thread 'main' panicked at 'create tokio runtime: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', /home/rafael/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.5.0-rc.1/src/lib.rs:232:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

5. With RUST_BACKTRACE=1 cargo run:

thread 'main' panicked at 'create tokio runtime: Os { code: 22, kind: InvalidInput, message: "Invalid argument" }', /home/rafael/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.5.0-rc.1/src/lib.rs:232:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/0a8629bff642c3c3b84bb644c0099194f063b627/library/std/src/panicking.rs:515:5
   1: core::panicking::panic_fmt
             at /rustc/0a8629bff642c3c3b84bb644c0099194f063b627/library/core/src/panicking.rs:92:14
   2: core::result::unwrap_failed
             at /rustc/0a8629bff642c3c3b84bb644c0099194f063b627/library/core/src/result.rs:1355:5
   3: core::result::Result<T,E>::expect
             at /rustc/0a8629bff642c3c3b84bb644c0099194f063b627/library/core/src/result.rs:997:23
   4: rocket::async_main
             at /home/rafael/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket-0.5.0-rc.1/src/lib.rs:226:5
   5: rocket_pastebin::main
             at ./src/main.rs:4:18
   6: core::ops::function::FnOnce::call_once
             at /rustc/0a8629bff642c3c3b84bb644c0099194f063b627/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Maybe this behavior comes from the code cargo downloads from crates.io? 🤔

[SergioBenitez]

I've was able to reproduce with input from @Darksonn and @carllerche on the tokio side. This is a bug in mio, the underlying non-blocking API library used by tokio. Related issues: tokio-rs/mio#1495, tokio-rs/mio#1497.

Will update with a course of action.

[Thomasdezeeuw]

I've pulled Mio v0.7.12 which introduced this bug, so it should be fixed now.

[SergioBenitez]

The affected mio release was just yanked. This means a cargo update should result in Cargo pulling the last non-yanked mio release, 0.7.11, which doesn't contain this bug. This resolves the issue in my reproduced environment.

@whb07, can you confirm that cargo update resolves this issue?

[Azgrom]

It worked for me!

[SergioBenitez]

This should now be resolved. If this is not the case, please reopen this issue.

[whb07]

Yep good to go, ran on fedora and ubuntu 21 for kicks and everything runs fine.