Stale nojava-ipmi-kvmrc containers block noVNC ports after server stop

[nesvet]

Summary

With nojava-ipmi-kvm-server v0.2.2 in Docker and WEB_PORT_START / WEB_PORT_END set (for example 18282–18283, exclusive end), stopping the server without a clean WebSocket close leaves an orphaned nojava-ipmi-kvmrc-<uuid> container holding the noVNC host port.

Symptoms

After server exit (SIGTERM, exit 143) while the browser tab stayed open:

NAMES                          STATUS              PORTS
nojava-ipmi-kvmrc-085f5167…    Up                  0.0.0.0:18282->8080/tcp
nojava-ipmi-kvm                  Exited (143)

The next connect attempt fails with Docker return code 125:

Bind for 0.0.0.0:18282 failed: port is already allocated

Root cause

Child cleanup runs in KVMHandler.on_close() only. Server shutdown does not invoke it, so a live child can outlive the server process.

Proposed design

Two coordinated changes:

1. Library — sciapp/nojava-ipmi-kvm#38: cleanup_stale_kvm_children() before each session, async-safe Docker subprocess usage, and clearer messaging when exit code 125 indicates a port conflict.
2. Server — sciapp/nojava-ipmi-kvm-server#9: run the same helper after config load, on SIGTERM, and at process exit; cancel an in-flight connect task on WebSocket close so a partial session does not outlive the browser tab.

Stale removal should target nojava-ipmi-kvmrc-* that are exited/dead or bind a host port in [WEB_PORT_START, WEB_PORT_END). Containers outside that range must be left alone on shared Docker hosts.

Reproduction

1. Start a KVM session through the web UI.
2. Stop the server container without closing the browser tab.
3. Start the server again and connect — failure until manual docker rm on the orphan.

Tested on ASUS ASMB8-iKVM firmware 1.14.2. After server restart following an open session, stale children are removed and reconnect succeeds without manual cleanup.