shuttle-hq
[Bug]: Port left open when shutting down the runtime server in the event of certain crashes
What happened?
This came up from this PR.
It seems like the runtime isn't always shutting down the ports it uses in the event of certain crashes.
Version
0.14.0
Which operating system(s) are you seeing the problem on?
macOS
Which CPU architectures are you seeing the problem on?
ARM64
Relevant log output
No response
Duplicate declaration
- [X] I have searched the issues and there are none like this.
Wondering if there's any movement on this? I'd be happy to go bug hunting if someone could chip in to guess what might be the issue here. Just want to make sure I'm roughly looking in the right place before I spend too much time looking around.
Yesterday I had the same issue:
thread 'main' panicked at 'Error while serving address 127.0.0.1:7999: transport error', /Users/user1/.cargo/registry/src/index.crates.io-6f17d22bba15001f/shuttle-runtime-0.24.0/src/alpha/mod.rs:105:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: status: Unknown, message: "transport error", details: [], metadata: MetadataMap { headers: {} }
Caused by:
0: transport error
1: http2 error: stream error received: stream no longer needed
2: stream error received: stream no longer needed', /Users/user1/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cargo-shuttle-0.24.0/src/lib.rs:864:51
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
I use MacOS (Intel)
Fixed with kill $(lsof -t -i:7999)
Wondering if there's any movement on this? I'd be happy to go bug hunting if someone could chip in to guess what might be the issue here. Just want to make sure I'm roughly looking in the right place before I spend too much time looking around.
That would be great, Boyd! This is the top function for local runs on Unix, so there is likely some loophole in how we handle signals here/how we handle runtime crashes. I would start by finding a way to reliably reproduce the issue on a Unix system (we don't have reports for this on Windows, I think).
Okay cool 👍 I'll go digging and see what I can find. Might be a little while though, work is pretty busy at the moment.
We have added a prompt if cargo-shuttle detects that the wanted ports are occupied a while ago, but it is possible that child processes are still being left running sometimes. Any further reports and steps to reproduce are appreciated.
