pallets / flask

The Python micro framework for building web applications.
https://flask.palletsprojects.com
BSD 3-Clause "New" or "Revised" License
67.5k stars 16.14k forks source link

Failing to start (due to port unavailable) cannot be directly determined by the current python api #5471

Closed matanox closed 4 months ago

matanox commented 4 months ago

I believe that failing to start (due to the designated port being unavailable) cannot be directly determined by the current python api, if not mistaken.

When the port specified for startup is taken, a python code starting the server with Werkzeug cannot know if startup has failed, since no exception is raised, and no api is there to check on its status, while the following is written to stderr:

Address already in use Port 5000 is in use by another program. Either identify and stop that program, or start the server with a different port.

example code:

from flask import Flask
from werkzeug.serving import run_simple

app = Flask(__name__)

try:
    run_simple('127.0.0.1', 5000, app)  
except Exception as e:
    start_success = False

Even though traditionally most web servers frameworks did not touch up their startup and shutdown usability from code to those levels, I think it would be implied to provide the caller with this basic level of transparency being robustly enabled for them. Apologies in advance if I've missed any obvious way.

Environment:

Mildly related on the same theme of api startup and shutdown:

https://stackoverflow.com/questions/72824420/how-to-shutdown-flask-server

matanox commented 4 months ago

Complete code reproducing the context, which would hopefully also become a skeleton (or inspiration) for a flaks test, after an api transparency into failure to use the specified server port has been very hopefully incorporated in flask:

from flask import Flask
from werkzeug.serving import run_simple
from multiprocessing import Process

app = Flask(__name__)

def start():
    print('starting a flask server')
    try:
        started = run_simple('127.0.0.1', 5000, app)
    except Exception as e:
        print(f'the flask web server crashed with an exception:\n{e}\n')
    else:
        # of course we will never get here unless the server shut down without throwing
        print(f'the flask web server finished with return value {started}')

if __name__ == '__main__':

    flask_process = Process(target=start, daemon=True)
    flask_process.start()

    start()

Note that, the messages about the port being unavailable come out on stderr, same as success messages such as the following type, and hence this leaves no deterministic way for the code starting the server to resolve the status of the server, other than parsing stderr:

127.0.0.1 - - [28/Apr/2024 13:31:24] "GET / HTTP/1.1" 200 -

ThiefMaster commented 4 months ago

Not sure what you are trying to do, but keep in mind that this server is ONLY meant for development purposes, NOT for anything else. So if you want to run a flask app embedded in some other application for whatever reason, using run_simple is not what you should do.

matanox commented 4 months ago

Makes sense. My scenario is borderline in that regard. Will I have that kind of api-laden way of knowing the status of the server when using a non Werkzeug WSGI component?

matanox commented 4 months ago

Okay, I understand then that no underlying supported WSGI server component can be controlled (start and stop) robustly from Flask code then, and that that is not planned either.