You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think I have a hunch going through the logs: They are full of:
Sun Jan 24 20:54:35 2021 - *** uWSGI listen queue of socket "0.0.0.0:5000" (fd: 3) full !!! (101/100) ***
Sun Jan 24 20:54:36 2021 - *** uWSGI listen queue of socket "0.0.0.0:5000" (fd: 3) full !!! (101/100) ***
Sun Jan 24 20:54:37 2021 - *** uWSGI listen queue of socket "0.0.0.0:5000" (fd: 3) full !!! (101/100) ***
Now add the following to the mix:
WSGI app 0 (mountpoint='/sipa') ready in 134 seconds on interpreter 0x55ebba9f86b0 pid: 95268 (default app)
This together with Git fetch failed suggests to me that on startup, SIPA waits for the fetch until it times out. In thea meantime, a lot of requests (even if it's just HEAD / from a proxy) build up and flood the listen queue so the worker commits HARAKIRI.
There are multiple options for this:
Quickfix: Figure out whether we can decrease the timeout for the git fetch and increase the listen queue capacity
Proper fix: Establish some kind of „health check“ either before all of the start startup, or before trying to fetch the git repo. This may e.g. just be a ping to the git server.
When SIPA loses its Internet access, it becomes unresponsive.
Maybe because it tries to fetch other services, such as the Pycroft backend or PBX?
The text was updated successfully, but these errors were encountered: