AttributeError: module 'select' has no attribute 'epoll' #2848
Comments
|
Are you running Linux? It appears so and https://docs.python.org/3.11/library/select.html#select.epoll reads like it should be fairly available. Maybe the wrong |
|
@altendky thank you for reply, Yes I am running linux based operating system. |
|
So Trio does assume that Python will have https://github.com/python-trio/trio/blob/v0.22.2/trio/_core/_run.py#L2541-L2543 elif sys.platform == "linux" or (not TYPE_CHECKING and hasattr(select, "epoll")):
from ._generated_io_epoll import *
from ._io_epoll import EpollIOManager as TheIOManagerBut Python checks to see if it is available on the system at compile time. It looks like this is set via the configure script. https://github.com/python/cpython/blob/v3.11.6/Modules/selectmodule.c#L1230 #ifdef HAVE_EPOLLCould you review this 'script' to make sure you are comfortable running it, and if so, share back the output? (after reviewing the output for anything you might be concerned about sharing
For example, I get this output (for my Python 3.10 instead) showing that epoll seems to be enabled in both the kernel and in Python. $ echo ---- python select && /usr/bin/python3.10 -c 'import select; print(select); print(getattr(select, "epoll", None))' && echo ---- python config && python -c 'import sysconfig; config = sysconfig.get_config_vars(); print({key: value for key, value in config.items() if "EPOLL" in key})' &&echo ---- uname && uname -a && echo ---- lsb_release && lsb_release -a && echo ---- boot config && grep -r EPOLL /boot/config* && echo ---- proc && grep -ri epoll /proc/sys/kernel/
---- python select
<module 'select' (built-in)>
<class 'select.epoll'>
---- python config
{'HAVE_EPOLL': 1, 'HAVE_EPOLL_CREATE1': 1, 'HAVE_SYS_EPOLL_H': 1}
---- uname
Linux p1 6.2.0-36-generic #37~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Oct 9 15:34:04 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
---- lsb_release
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
---- boot config
/boot/config-5.19.0-46-generic:CONFIG_EPOLL=y
/boot/config-6.2.0-35-generic:CONFIG_EPOLL=y
/boot/config-6.2.0-36-generic:CONFIG_EPOLL=y
---- proc
grep: /proc/sys/kernel/apparmor_display_secid_mode: Permission denied
grep: /proc/sys/kernel/apparmor_restrict_unprivileged_userns: Permission denied
grep: /proc/sys/kernel/apparmor_restrict_unprivileged_userns_complain: Permission denied
grep: /proc/sys/kernel/apparmor_restrict_unprivileged_userns_force: Permission denied
grep: /proc/sys/kernel/cad_pid: Permission denied
grep: /proc/sys/kernel/unprivileged_userns_apparmor_policy: Permission denied
grep: /proc/sys/kernel/usermodehelper/bset: Permission denied
grep: /proc/sys/kernel/usermodehelper/inheritable: Permission denied |
no, you're just getting a bunch of permission errors. Running it on my system with zcat /proc/config.gz | grep -i EPOLLWas suggested by the internet for checking EPOLL availability though, and works on my system - so @kushalmraut might want to run that in addition and check the output in case their system differs from altkendy. |
|
Output for the script is: |
|
@jakkdl |
|
I'm struggling to reconcile: And yet (I don't have anything productive to add, just found this puzzling). |
|
yeah this is very strange. It feels like there might be a bug in gunicorn or something being misconfigured somehow such that the python/ |
|
Please let me elaborate in detail. This is my os
when i specify workers in gunicorn configurations i get this error. I search for this issue and followed following links but unable to fix it. followed references. Please let me know if you find solution or root of cause. |
hm, is it a problem with virtualenvs or similar? Some questions to help you narrow down the problem: Do you also get it in CI? Tried a clean virtualenv? What distro? How did you do the python version upgrade? If you create a new project can you reproduce the problem? Does the problem disappear if you revert the upgrade? |
I don't have CL if you're referring to the continuous integration. I have created a new virtualenv with python 3.11 while upgrading the packages instate of upgrading previous virtualenv. distro I have installed a 3.11 separately used this reference for python installation The issue is reproduced when new project is created. I have two servers stage and main and issue is for both. The problem is disappear when i switch to the old virtualenv. |
did you ever try this? |
Yes I have tried adding I have also deleted the python 3.11 and old vertualenv and installed python 3.11 again and created new vertualenv and tried it again but getting the same error. I have printed
|
and then add it to every other location in the backtrace, to figure out where it breaks. The big question mark is why you can run it in the python prompt w/o error but it breaking deep down in the call stack when trio tries to do it |
|
I've dug this problem and got this result. I add And got this output But I'm not good at Exactly same code works with Python 3.9.16. But not with 3.11.7 (nor 3.12.1). Same gevent version (23.9.1) is used. |
|
select module has been monkey patched so if you are using gevent and gunicorn this error will occure in runtime. |
|
Got it. |
|
Oh huh I see the problem now. I think a solution would be to use a lambda and reference select.epoll inside (assuming you don't actually end up using trio?) But a workaround as a user might be to just |
|
Running: |
|
I solved my problem by uninstalling The comment from @jeongilpark sparked the thought. Thank you! |
|
The problem arises with the use of worker_class “gevent” when changing it to “gthread” it no longer throws the error. This worked for me. |
|
I think it should be fine that this issue is closed, technically we've halfway solved the problem, Trio will not crash on import with #2928 being merged now, but the root problem is still not fixed, which I think might be better suited for a new issue (or maybe one already exists). |
This fixed it for me too. You made my day so much easier!! <3 |
version : trio==0.22.2
I am getting above error if I specify the workers in gunicorn config.
gunicorn service file
The text was updated successfully, but these errors were encountered: