Is your feature request related to a problem? Please describe.
Yes.
Currently, if the port specified with -port is already in use, Visdom crashes with a cryptic OSError due to this users have to manually find a free port and then have to restart the server. This is especially challenging for beginners and when running multiple instances of Visdom.
Describe the solution you'd like
I propose adding a graceful auto-retry mechanism in run_server.py:
If the requested port is busy, automatically try the next ports (up to 10 attempts by default).
Clearly inform the user which port the server finally started on.
Keep the behavior safe (never exceed 65535) and use proper logging.
This would make the server much more user-friendly without breaking existing workflows.
Describe alternatives you've considered
Keep the current behavior (aborted execution) and add --auto-retry flag, but default auto-retry feels more convenient.
Let the OS choose a random port when port=0.
Additional context
This was discussed in my previous PR(#1128). @marcoag suggested opening an issue first to discuss the approach before submitting a cleaner PR.
I already have a clean, tested implementation ready (with proper logging, safety checks, and clear messages).
Happy to adjust the design based on the feedback.
Is your feature request related to a problem? Please describe.
Yes.
Currently, if the port specified with -port is already in use, Visdom crashes with a cryptic OSError due to this users have to manually find a free port and then have to restart the server. This is especially challenging for beginners and when running multiple instances of Visdom.
Describe the solution you'd like
I propose adding a graceful auto-retry mechanism in
run_server.py:If the requested port is busy, automatically try the next ports (up to 10 attempts by default).
Clearly inform the user which port the server finally started on.
Keep the behavior safe (never exceed 65535) and use proper logging.
This would make the server much more user-friendly without breaking existing workflows.
Describe alternatives you've considered
Keep the current behavior (aborted execution) and add --auto-retry flag, but default auto-retry feels more convenient.
Let the OS choose a random port when port=0.
Additional context
This was discussed in my previous PR(#1128). @marcoag suggested opening an issue first to discuss the approach before submitting a cleaner PR.
I already have a clean, tested implementation ready (with proper logging, safety checks, and clear messages).
Happy to adjust the design based on the feedback.