Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
matanox opened this issue Apr 28, 2024 · 4 comments

Comments

@matanox
Copy link

matanox commented Apr 28, 2024

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:

  • Python version: 3.10.13
  • Flask version: 3.0.3
  • Platform: Ubuntu 22.04

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

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

@matanox
Copy link
Author

matanox commented Apr 28, 2024

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
Copy link
Member

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
Copy link
Author

matanox commented Apr 28, 2024

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?

@davidism davidism closed this as not planned Won't fix, can't repro, duplicate, stale Apr 28, 2024
@matanox
Copy link
Author

matanox commented Apr 29, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants