Server never releases port when killed when using cargo-watch

[aVikingTrex]

I am currently attempting to develop a server with actix-web using cargo watch. I am using the simple invocation of
cargo watch -x run. I am new to both actix-web and rust so I may be doing something obviously incorrect here and I apologize if it is something obvious.

Expected Behavior

The server should correctly be hot-reloaded on a file save when a change occurs.

Current Behavior

The rebuild is initiated but then hangs when starting the server again. The reported error is address in use. Right now I have a minimal example as my current stage of implementation is stubbing out an API.

Steps to Reproduce (for bugs)

An example of how I am building each endpoint

#[get("/")]
async fn home() -> impl Responder {
    format!("Home page")
}

An example of a service implementation

async fn account() -> impl Responder {
    HttpResponse::Ok().body("This is the account management page")
}

pub fn members_service(cfg: &mut web::ServiceConfig) {
    cfg.service(account).service(members_tool);
}

The main function used to run the server

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    HttpServer::new(|| {
        App::new()
            .configure(auth::auth_service)
            .configure(members::members_service)
            .service(home)
    })
    .bind("127.0.0.1:8080")?
    .shutdown_timeout(1) // 0 doesnt work either
    .run()
    .await
}

Your Environment

Linux LTS: 5.15.91-4-lts

• Rust Version (I.e, output of rustc -V): rustc 1.66.0 (69f9c33d7 2022-12-12)
• Actix Web Version: 4.3.0

[jdevries3133]

I was experiencing this issue too. I resolved it by updating cargo-watch from v8.3.0 to v8.4.0.

The release notes give a clue of what might have been going wrong:

Fix a critical bug where signals sent to commands (including the ones cargo watch would send!) would not be handled due to rust-lang/rust#101077. (watchexec/cargo-watch#249, watchexec/cargo-watch#247)

(source: https://github.com/watchexec/cargo-watch/releases/tag/v8.4.0)

Maybe we can add a documentation patch on this page (https://actix.rs/docs/autoreload/) to warn users of this recent issue. I can contribute the patch; I'll do it right now.

[robjtede]

I'm glad the cause has been identified but I don't think this deserves a note on the website. We'll pin this issue for a couple weeks, though.