`dx serve` panic: Could not receive a socket - the devtools could not boot - the port is likely already in use

[david-boles]

Problem

$ RUST_BACKTRACE=1 dx serve
2024-09-04T21:05:36.662764Z  INFO dx::builder::cargo: 🚅 Running build [Desktop] command...
2024-09-04T21:05:36.663218Z  INFO dx::builder::cargo: 🚅 Running build [Desktop] command...
thread 'main' panicked at /home/deb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/dioxus-cli-0.6.0-alpha.2/src/serve/server.rs:267:21:
Could not receive a socket - the devtools could not boot - the port is likely already in use
stack backtrace:
   0: rust_begin_unwind
   1: core::panicking::panic_fmt
   2: dx::serve::serve_all::{{closure}}::{{closure}}
   3: dx::serve::serve_all::{{closure}}
   4: tokio::runtime::park::CachedParkThread::block_on
   5: dx::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
$ dx --version
dioxus 0.6.0-alpha.2 (was built without git repository)

Steps To Reproduce

Steps to reproduce the behavior:

• Unsure; I've run into this twice now, my system somehow seems to get stuck in this state. It's worked fine before.

Expected behavior

No panic.

Environment:

• Dioxus version: 0.6.0-alpha.2
• Rust version: Probably 1.80.1? Not sure what it got installed with.
• OS info: Ubuntu 20.04.6 LTS, 5.15.0-119-generic
• App platform: Fullstack

[david-boles]

I believe rebooting my machine fixed it. It may have also been reinstalling the CLI.

I'm fairly sure the port wasn't already in use; I didn't have any other instances of dx running and I tried adding a debug print for the port number returned by get_available_port and nothing else seemed to be bound to it.

[david-boles]

Hmm, I did get this error when I had another instance of dx serve running for a different project. If that's why I was hitting this before I'm not sure why ps aux | grep dx didn't turn up anything.

Is there some other fixed port that it's referencing? Bound to by the server itself?

[jkelleyrtp]

I added logic in #3586 that will auto-select free ports. I think your case is an instance where an instance of dx didn't die properly (zombie process) but the issue with conflicting ports shouldn't occur anymore.