Bug Fix: Update the port scanning logic to properly skip ports in use #6560
Conversation
There was a problem hiding this comment.
Thanks for addressing this! I wonder a little whether this may be quite slow in some cases (e.g. if connecting to the "test" socket will time out or otherwise fail in a less-than-clean way) but I suppose users can always pass a hardcoded port or script it (as you had in the issue) as a workaround.
The current Werkzeug version is 3.3.7
Just checking, I assume you mean 2.3.7? (that's the latest I can find)
I looked at the Werkzeug code and this commit looks like probably the culprit (moves the sys.exit() call introduced in this commit from a codepath I believe we don't call into one that we do).
Presumably Werkzeug is fine with this change being unfriendly to our use case, since they don't want people using their WSGI server for non-development purposes anyway 😒
tensorboard/program.py
Outdated
| for port in range(base_port, base_port + max_attempts): | ||
| subflags = argparse.Namespace(**vars(flags)) | ||
| subflags.port = port | ||
| if is_port_in_use(port): |
There was a problem hiding this comment.
Doing the port-in-use check here won't respect the should_scan logic (based on flags.port).
Can we instead move it closer to where the logic previously happened (when binding to the socket would raise the exception)? I.e. move it into WerkzeugServer.__init__() before the call to the superclass init (which is where we'll attempt binding the socket) and make it raise TensorBoardPortInUseError, which will then trigger the existing except logic on the lines below.
There was a problem hiding this comment.
This portion of the code is a bit complicated so while I think I've made the suggested change, please let me know if I've missed something.
I do mean 2.3.7, I've update the description. |
Motivation for features / changes
#6552
Technical description of changes
The port scanning logic originally added in #1851 does not seem to work anymore. WerkzeugServer no longer raises an Error when attempting to bind to a port which is in used and instead handles the issue silently.
The current Werkzeug version is 2.3.7 but I had 2.3.4 installed when I first verified this. I tried installing 2.2.0 and the issues was not present so I assume it was introduced in 2.3.0.
https://pypi.org/project/Werkzeug
Detailed steps to verify changes work correctly (as executed by you)