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

Gunicorn worker fails to boot due to NotImplementedError #2960

Open
codebanesr opened this issue Feb 19, 2024 · 4 comments
Open

Gunicorn worker fails to boot due to NotImplementedError #2960

codebanesr opened this issue Feb 19, 2024 · 4 comments

Comments

@codebanesr
Copy link

Description:
I'm encountering a NotImplementedError: unsupported platform which causes my Gunicorn worker process to fail. This seems to be originating from the httpx/trio libraries. Has anyone else experienced similar issues?

Error Traceback:

[2024-02-18 21:08:17 -0800] [42822] [ERROR] Exception in worker process
Traceback (most recent call last):
 File "/opt/homebrew/lib/python3.11/site-packages/gunicorn/arbiter.py", line 609, in spawn_worker
  worker.init_process()
 File "/opt/homebrew/lib/python3.11/site-packages/gunicorn/workers/ggevent.py", line 147, in init_process
  super().init_process()
 File "/opt/homebrew/lib/python3.11/site-packages/gunicorn/workers/base.py", line 134, in init_process
  self.load_wsgi()
 File "/opt/homebrew/lib/python3.11/site-packages/gunicorn/workers/base.py", line 146, in load_wsgi
  self.wsgi = self.app.wsgi()
        ^^^^^^^^^^^^^^^
  ... (Remainder of traceback) 
NotImplementedError: unsupported platform

Environment:

  • OS: Mac M2 [darwin]
  • Python: 3.11.7
  • Gunicorn: version 21.2.0
  • httpx: Version (output of pip show httpx)
Name: httpx
Version: 0.25.0
Summary: The next generation HTTP client.
Home-page: 
Author: 
Author-email: Tom Christie <tom@tomchristie.com>
License: 
Location: /opt/homebrew/lib/python3.11/site-packages
Requires: certifi, httpcore, idna, sniffio
Required-by: anthropic, gotrue, openai, postgrest, qdrant-client, storage3, supabase, supafunc
  • trio: Version (output of pip show trio)
Name: trio
Version: 0.23.1
Summary: A friendly Python library for async concurrency and I/O
Home-page: https://github.com/python-trio/trio
Author: Nathaniel J. Smith
Author-email: njs@pobox.com
License: MIT OR Apache-2.0
Location: /opt/homebrew/lib/python3.11/site-packages
Requires: attrs, idna, outcome, sniffio, sortedcontainers
Required-by: selenium, trio-websocket

Let me know if any more details are necessary.

@codebanesr
Copy link
Author

codebanesr commented Feb 19, 2024

The error originates here, and it only happens when i try to run the app with gunicorn and eventlet
Screenshot 2024-02-18 at 9 19 15 PM

@CoolCat467
Copy link
Contributor

CoolCat467 commented Feb 19, 2024

This sounds incredibly similar to #2848.

EDIT:
In #2848, we found out that basically gevent monkey-patches some things in the select module and that breaks things for trio. Apparently this is intended according to gevent/gevent#2008.

According to gunicorn docs (https://docs.gunicorn.org/en/stable/settings.html#worker-class),
apparently you might want to create a subclass for gunicorn.workers.base.Worker that uses trio

EDIT II:
It might be worth looking into https://github.com/pgjones/hypercorn, which is also a wsgi server. I've personally had a lot of success working with it (my project sane scanner server uses it), and it has built-in support for a trio worker class.

@jakkdl
Copy link
Member

jakkdl commented Feb 19, 2024

The error originates here, and it only happens when i try to run the app with gunicorn and eventlet Screenshot 2024-02-18 at 9 19 15 PM

right yeah, if we're getting here in the logic then we're neither on windows nor linux (true), and the select module does not appear to have kqueue (so apparently gevent.select does not have kqueue either. So indeed similar to #2848, but would not be resolved by #2928.

@A5rocks
Copy link
Contributor

A5rocks commented Feb 19, 2024

Yeah in #2928 I could make things work via gevent.monkey.get_original but I don't think that's really the right behavior. That will make trio.run block, I think.

Not entirely sure what is the best outcome to have here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants