rwf2 / Rocket

A web framework for Rust.
https://rocket.rs
Other
24.17k stars 1.55k forks source link

Rocket 0.5.0-dev deadlocks on futex when compiled with x86_64-unknown-linux-musl target right after binding port #1469

Closed yasammez closed 3 years ago

yasammez commented 3 years ago

rustc --version

rustc 1.47.0 (18bv6b4f0 2020-10-07)

rocket version from Cargo.lock

name = "rocket"
version = "0.5.0-dev"
source = "git+https://github.com/SergioBenitez/Rocket#2f98299272a2a196a3d053918ebd542e03abfc70"

Minimal example

Cargo.toml

[package]
name = "minimal"
version = "0.1.0"
authors = ["Liv Fischer"]
edition = "2018"

[dependencies]
rocket = { git = "https://github.com/SergioBenitez/Rocket" }

main.rs

#[macro_use] extern crate rocket;

#[get("/health")]
fn health() -> &'static str {
  "Up"
}

#1347 fn rocket() -> rocket::Rocket {
  rocket::ignite()
    .mount("/", routes![health])
}

Compiling and running this on x86_64-pc-windows-gnu in cygwin works fine. But compiling with cargo build --target x86_64-unknown-linux-musl --release (debug build seems fine) hangs indefinitely.

Expected behaviour

Configured for debug.
    => address: 127.0.0.1
    => port: 8000
    => workers: 16
    => log level: normal
    => secret key: [zero]
    => limits: forms = 32KiB
    => cli colors: true
    => keep-alive: 5s
    => tls: disabled
Mounting /:
    => GET /health (health)

Actual behaviour

strace output (truncated)

epoll_ctl(3, EPOLL_CTL_ADD, 6, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLET, {u32=0, u64=0}}) = 0
brk(0x564de1356000)                     = 0x564de1356000
socketpair(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0, [7, 8]) = 0
brk(0x564de1357000)                     = 0x564de1357000
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x564de08a8b10, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO|SA_NOCLDSTOP, sa_restorer=0x564de08f5716}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
fcntl(7, F_DUPFD_CLOEXEC, 0)            = 9
fcntl(9, F_SETFD, FD_CLOEXEC)           = 0
epoll_ctl(3, EPOLL_CTL_ADD, 9, {EPOLLIN|EPOLLPRI|EPOLLOUT|EPOLLET, {u32=1, u64=1}}) = 0
getsockname(6, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("127.0.0.1")}, [128->16]) = 0
futex(0x7ffe331e9284, FUTEX_WAIT_PRIVATE, 2, NULL

Note that this is in fact the end of the strace output, it cuts off just in the middle of the futex syscall.

jebrosen commented 3 years ago

Hm, I deployed a build of x86_64-unknown-linux-musl earlier this week without a similar issue.

You mentioned x86_64-pc-windows-gnu - are you also building and running the musl target inside cygwin, or in another environment like WSL (1 or 2) or a hypervisor?

SergioBenitez commented 3 years ago

Have you tried sending a request to the server, @yasammez? As of the config revamp, Rocket no longer prints configuration information by default on release. Does ROCKET_LOG_LEVEL=normal resolve the issue?

yasammez commented 3 years ago

Thanks for your reply!

You mentioned x86_64-pc-windows-gnu - are you also building and running the musl target inside cygwin, or in another environment like WSL (1 or 2) or a hypervisor?

Unfortunately my employer won't let me use WSL, so I am stuck with cygwin on my development machine. The musl target gets packed into a docker container and is deployed unto a RedHat OSCP cluster which automaticall generates HTTP requests as health checks every second. None of these came back successful. But I will try again on Monday.

SergioBenitez commented 3 years ago

This could also be #1457. Are you setting the address to 0.0.0.0 on release, and generally have you updated your configuration structure for the revamped config? See https://rocket.rs/master/guide/configuration/.

yasammez commented 3 years ago

No I had not. Thank you very much, this resolves the issue!