[desktop/tellurida] telluride does not shutdown when frostwire is shutdown about frostwire HOT 15 CLOSED

Thank you for letting me know this is happening, that is not the intentional behaviour.
FrostWire sends a shutdown command to the server on exit, perhaps something broke with one of the python library updates.

I'll check and let you know if I can replicate/fix

from frostwire.

can't replicate on macOS (arm64), with FrostWire 6.9.9.

Will test on Windows.

(On what operating system are you on @jjgalvez, please make sure you're running FrostWire 6.9.9)

from frostwire.

can't replicate on macOS (arm64), with FrostWire 6.9.9.

Will test on Windows.

(On what operating system are you on @jjgalvez, please make sure you're running FrostWire 6.9.9)

sorry the OS is a valuable piece of information I should have included.

OS Arch Linux
Forstwire version 6.9.9
installed form the official targz file.

An interesting note is that when I ran telluride_linux -h I saw that I should have been able to shut down the service with the shutdown command but trying
curl 'http://127.0.0.1:47999/?shutdown=1'
echos a shutdown message but does not shutdown the server.

happy to provide any additional info that might be helpful as well as test things again if its helpful.

from frostwire.

FYI running the server.py code locally I noticed that request.environ.get('werkzeug.server.shutdown') returned none, so I modified the code:
I imported os and signal and then edited your route_handler function

  @app.route('/')
  def root_handler():
      '''
      http handler, rejects connections not coming from localhost|127.0.0.1
      url parameters:
      url=<url encoded video page url to obtain json metadata from>
      [shutdown=1] if passed it will shutdown the server
      '''
      gtfo = reject_remote_requests()
      if gtfo is not None:
          return gtfo

      query = request.args.to_dict()
      print(query)
      if 'shutdown' in query and (query['shutdown'] == '1' or query['shutdown'].lower() == 'true'):
          shutdown_function = request.environ.get('werkzeug.server.shutdown')
          if shutdown_function is not None:
              shutdown_function()
          else:
              try:
                  os.kill(os.getpid(), signal.SIGINT)
              except:
                  print("can't kill service")
          return jsonify({'message':'shutdown'})
      if 'url' in query:
          return query_video(query['url']), 200
      return jsonify({'build' : build_number, 'message': 'no valid parameters received'})

that killed the service on my rig, hope it helps. not sure if it works for windows and mac which is why I wrapped it in a try-except statement

from frostwire.

Not sure if I want to add more imports (perhaps I've already imported those on other modules).

Can you please start a branch and send a PR so I can see exactly what you changed?

We should first understand why we're not getting the shutdown function in your environment and not patch around with a kill and what not, we'd like to shutdown gracefully and include as little as possible to minimize the size of the executable.

from frostwire.

Finding stuff out there:

The 'environ['werkzeug.server.shutdown']' function is deprecated and will be removed in Werkzeug 2.1.

from frostwire.

This was added in #36 as a way to shutdown local applications, environ["werkzeug.server.shutdown"](). 
However, the advice for quite some time has been to use a production server even when running local applications; 
the development server is  only for development.

The issue and code comments both describe the implementation as "horrible".

The implementation of it is in fact pretty  weird, having to touch a double underscore "really private" variable, as well as jump through hoops to work with the  HTTP server loop and handle reloader processes.

Additionally, users see this and then are confused why they can only shut down their application when using the 
development server. 
Or they want to be able to do more process management such as reloads, which is definitely out of 
scope.

from frostwire.

it appears they've added a server.shutdown() command, perhaps we should play with that instead and not depend on the request.environ.get('werkzeug.server.shutdown') which also looks like a pretty bad hack reaching out for something that seems to be a global reference.

from frostwire.

Learning more, it seems the root cause of our problem is that we're currently running Flask with the Flask.run() method which is meant only for development environment. This server isn't efficient at all according to the documentation and they recommend you embed Flask into a real WSGI server.

They recommend a few and it seems Waitress could be a good option
https://flask.palletsprojects.com/en/2.2.x/deploying/waitress/

If this becomes too heavy to add, then I'll just go for the os.kill() solution. Although I don't know how effective that will be across all the different OSes.

from frostwire.

Going with your solution for now @jjgalvez
427ea74

from frostwire.

Like I said happy to test anything I'll fork and send a pr later this evening

from frostwire.

awesome, please git pull and give it a try now.

from frostwire.

tested on linux arch and now it exits as expected with shutdown=1, I have not tested on windows yet but will. I don't have access to a mac so I can't test there

from frostwire.

just tested on windows 11 and it also seems to be working

from frostwire.

Thank you so much for testing.
Will go ahead and close this.

from frostwire.