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

uWSGI listen queue of socket full #147

Closed
StefanoSperetta opened this issue Jan 9, 2024 · 5 comments
Closed

uWSGI listen queue of socket full #147

StefanoSperetta opened this issue Jan 9, 2024 · 5 comments

Comments

@StefanoSperetta
Copy link
Member

After the app has run for quite some time, the webserver stops working.
This error can be seen in the logs:

app_1 | Tue Jan 9 04:04:46 2024 - *** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***

This is probably the solution.

If WSGI starts responding slowly, nginx might have already closed the connection, throwing an error.

@StefanoSperetta
Copy link
Member Author

It seems the feature is working but some more testing is needed...

proxy_1       | 86.88.247.37 - - [09/Jan/2024:21:53:21 +0000] "GET /next-pass/39428/ HTTP/2.0" 200 935 "https://delfispace.tudelft.nl/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"
app_1         | [pid: 66|app: 0|req: 435/413] 86.88.247.37 () {52 vars in 1102 bytes} [Tue Jan  9 21:53:21 2024] GET /next-pass/39428/ => generated 935 bytes in 10 msecs (HTTP/2.0 200) 5 headers in 158 bytes (1 switches on core 1)
app_1         | Tue Jan  9 21:53:28 2024 - *** HARAKIRI ON WORKER 1 (pid: 66, try: 1, graceful: yes) ***
app_1         | Tue Jan  9 21:53:28 2024 - HARAKIRI !!! worker 1 status !!!
app_1         | Tue Jan  9 21:53:28 2024 - HARAKIRI [core 0] 86.88.247.37 - GET /location/all/ since 1704837203
app_1         | Tue Jan  9 21:53:28 2024 - HARAKIRI !!! end of worker 1 status !!!
app_1         | Tue Jan  9 21:53:28 2024 - HARAKIRI triggered by worker 1 core 0 !!!
proxy_1       | 86.88.247.37 - - [09/Jan/2024:21:53:28 +0000] "GET /location/all/ HTTP/2.0" 502 559 "https://delfispace.tudelft.nl/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"
app_1         | DAMN ! worker 1 (pid: 66) died, killed by signal 9 :( trying respawn ...
app_1         | Respawned uWSGI worker 1 (new pid: 69)
proxy_1       | 86.88.247.37 - - [09/Jan/2024:21:53:31 +0000] "GET /location/all/ HTTP/2.0" 200 197 "https://delfispace.tudelft.nl/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"
app_1         | [pid: 69|app: 0|req: 437/414] 86.88.247.37 () {52 vars in 1096 bytes} [Tue Jan  9 21:53:29 2024] GET /location/all/ => generated 197 bytes in 1769 msecs (HTTP/2.0 200) 5 headers in 158 bytes (1 switches on core 0)```

@StefanoSperetta
Copy link
Member Author

Interesting warning on the delfitlm_app container

*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers ***

@StefanoSperetta
Copy link
Member Author

Based on this, the last warning should be ignored.

@StefanoSperetta
Copy link
Member Author

The system has been stable over the last couple of days, this modification seems working fine.

@StefanoSperetta
Copy link
Member Author

No problem observed for months, the issue can be closed.

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

1 participant