Hi @regulartim, I have completed the migration from uWSGI to gunicorn. Could you please review the PR when you get a chance?

Also, I noticed the documentation at https://intelowlproject.github.io/docs/GreedyBear/Contribute/ still references the old greedybear_uwsgi container name.

There is also support for the uWSGI Protocol in Gunicorn, which seems to have advantages over http. Should be maybe use that?

Hey @SupRaKoshti ! Thanks for your work. Aside from the other comments, I checked the Gunicorn guide for docker deployments. They do some things a little different and I think we should match that in our default.yml:

• Dynamic calculation for the worker count
• Health Checks
• Graceful Shutdown

What do you think of that?

Hi @regulartim , that sounds great! I will look into the gunicorn Docker deployment guide and implement dynamic worker count calculation, health checks, and graceful shutdown. Give me some time to read through the documentation and I will update the PR accordingly.

Hey @SupRaKoshti ! :) Please also take a look at the uwsgi protocol support I mentioned:

There is also support for the uWSGI Protocol in Gunicorn, which seems to have advantages over http. Should be maybe use that?

If I understand it correctly using it would be more efficient and result in a smaller diff (=less changes to the code).

Also, I noticed the documentation at https://intelowlproject.github.io/docs/GreedyBear/Contribute/ still references the old greedybear_uwsgi container name.

Yeah, I'll just remove the command, it is outdated anyway.

Hey @regulartim! I have gone through the official Gunicorn documentation for Docker deployment and uWSGI protocol and implemented everything you suggested. Here's a summary of what was done:

Dynamic Worker Count

• Implemented using $((2 * $(nproc) + 1)) at runtime so workers automatically scale based on available CPUs in the container

Health Checks

• Since port 8001 now speaks uWSGI binary protocol (not HTTP), curl would fail
• Replaced with a Python TCP socket check in both default.yml and Dockerfile:

  python3 -c "import socket; socket.create_connection(('localhost', 8001), timeout=2)"
  

Graceful Shutdown

• Added --graceful-timeout 30 and --timeout 120 to the gunicorn command
• Added stop_grace_period: 30s to the app service to match

uWSGI Protocol

• Added --protocol uwsgi to the gunicorn command
• Updated http.conf and https.conf to use uwsgi_pass, uwsgi_cache and uwsgi_params instead of proxy_pass/proxy_cache
• django_server.conf intentionally kept as proxy_pass since it's only used in local dev with manage.py runserver which speaks plain HTTP

Gunicorn Log Directory

• Added ${LOG_PATH}/gunicorn directory creation in Dockerfile, same as we had for uWSGI

Service Renamed

• Renamed service from gunicorn to app across all compose files and updated all references in gbctl, nginx depends_on and qcluster depends_on

Ready for review! 🙏

Also @regulartim, I noticed that the app service currently runs as root, while qcluster already uses user: "2000:82". The Dockerfile already sets up www-data (uid 2000) and chowns all necessary directories, but USER www-data is never set and app service has no user: defined.

Should we implement the non-root user for the app service as well?

Pros:

• Security best practice — containers should not run as root
• Consistent with qcluster which already uses user: "2000:82"
• Recommended by the official Gunicorn Docker docs
• All file permissions are already correctly set up in the Dockerfile

Cons / Risks:

• entrypoint_gunicorn.sh runs chown -R 2000:82 /var/log/greedybear which requires root — this would need to be handled differently if we switch to non-root

Happy to implement this in a follow-up PR if you think it's worth doing!

Also @regulartim, I noticed that the app service currently runs as root, while qcluster already uses user: "2000:82". The Dockerfile already sets up www-data (uid 2000) and chowns all necessary directories, but USER www-data is never set and app service has no user: defined.
Should we implement the non-root user for the app service as well?

Yeah, I also thought about this. I would prefer to do that in a separate issue / PR though (feel free to open an issue). I am a bit scared that such a change might break existing instance.

Also, there seems to be a bug! When I try to run the container, I get:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "./docker/entrypoint_gunicorn.sh": permission denied

The reason might be that the file permissions of entrypoint_gunicorn.sh changed due to the renaming. Please check that. Maybe the executable bit is missing.

Hey @regulartim! I have implemented all the changes and suggestions you mentioned:

• Removed the redundant HEALTHCHECK from the Dockerfile since default.yml healthcheck already overrides it when running via Docker Compose
• Implemented the dual bind approach for the healthcheck — gunicorn now binds to port 8001 (uWSGI binary for nginx traffic) and port 8002 (plain HTTP for healthcheck only), so healthcheck requests bypass the uWSGI queue completely and use curl -f http://localhost:8002
• Fixed the missing executable bit (+x) on entrypoint_gunicorn.sh

Could you please review and check if everything is running fine? 🙏

Hey @SupRaKoshti ! The application does not even start. How are you testing your changes?

greedybear_app       | [2026-03-10 17:06:39 +0000] [112] [ERROR] Error handling request (no URI read)
greedybear_app       | Traceback (most recent call last):
greedybear_app       |   File "/usr/local/lib/python3.13/site-packages/gunicorn/workers/sync.py", line 141, in handle
greedybear_app       |     req = next(parser)
greedybear_app       |   File "/usr/local/lib/python3.13/site-packages/gunicorn/http/parser.py", line 56, in __next__
greedybear_app       |     self.mesg = self.mesg_class(self.cfg, self.unreader, self.source_addr, self.req_count)
greedybear_app       |                 ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
greedybear_app       |   File "/usr/local/lib/python3.13/site-packages/gunicorn/uwsgi/message.py", line 68, in __init__
greedybear_app       |     unused = self.parse(self.unreader)
greedybear_app       |   File "/usr/local/lib/python3.13/site-packages/gunicorn/uwsgi/message.py", line 104, in parse
greedybear_app       |     raise UnsupportedModifier(self.modifier1)
greedybear_app       | gunicorn.uwsgi.errors.UnsupportedModifier: Unsupported uWSGI modifier1: 71

Hey @regulartim , I apologize for that! I realized my mistake — I was testing with local.override.yml the whole time which uses Django's runserver instead of gunicorn, so the healthcheck was hitting port 8001 with plain HTTP and working fine on my end.

The root cause of the bug is that --protocol uwsgi applies globally to ALL binds including port 8002, so when curl sends an HTTP request to port 8002, gunicorn rejects it with UnsupportedModifier: 71 (modifier 71 = HTTP request on a uWSGI port).

I am now testing properly with docker compose -f docker/default.yml up and working through the issues step by step:

1. Replaced the curl healthcheck with nc -z localhost 8001 — container is now healthy. The InvalidUWSGIHeader: incomplete header errors in logs are just noise since nc -z sends no data.

2. Currently investigating ForbiddenUWSGIRequest — gunicorn's uWSGI protocol only trusts 127.0.0.1 by default and is rejecting requests from Nginx's Docker network IP, causing the Internal Server Error. Working on the fix now.

Will keep you updated as I progress. Sorry for the inconvenience!

Hi @regulartim ,

Update: After replacing the healthcheck with nc -z, I investigated the ForbiddenUWSGIRequest issue further and explored the following solutions:

• Option A (keep uWSGI): Fix the IP allowlist with --forwarded-allow-ips and properly quote the wildcard to avoid shell expansion issues. Keeps the original uWSGI design but is fragile — any mismatch in headers, IPs, or params breaks everything and is harder to debug.
• Option B (Unix socket): Bind gunicorn to a Unix socket to avoid the IP allowlist issue entirely. Needs extra volume mounting and path management.
• Option C (plain HTTP): Remove --protocol uwsgi from gunicorn and switch nginx from uwsgi_pass to proxy_pass with proxy_cache. Simplest to configure, debug, and maintain.

Option C fully resolves all the errors — no more ForbiddenUWSGIRequest or protocol-related issues.

My question: is the uWSGI protocol a hard requirement here? If not, I'd like to go with Option C (plain HTTP) as it eliminates all the protocol complexity. Happy to keep uWSGI if there's a specific reason for it!

Hey @SupRaKoshti ! :) UWSGI has some performance benefits over http. Therefore I would prefer to use it. The unix socket approach (option B) sounds smart. That would also have a positive effect on performance, I guess.

Hi @regulartim , Ready for review! here's a full summary of what i have done.

What was changed:

• Migrated Gunicorn from TCP (0.0.0.0:8001) to two UNIX sockets:
  • unix:/run/gunicorn-main.sock — all application traffic
  • unix:/run/gunicorn-health.sock — health checks only (separate socket to avoid queuing behind busy workers, as per your suggestion Bypass connection queue for load balancer health checks benoitc/gunicorn#1417)
• Added --preload flag to Gunicorn (explained below)
• Added shared gunicorn_sockets volume mounted at /run in both app and nginx containers
• Replaced app healthcheck with test -S /run/gunicorn-health.sock
• Updated nginx upstreams in http.conf and https.conf to use the two UNIX sockets
• Added dedicated /hc location in nginx routed to django_health upstream

Why UNIX sockets:
Gunicorn's uWSGI protocol only trusts 127.0.0.1 by default. Since nginx runs in a separate container with its own Docker network IP (172.20.0.x), every request was rejected with ForbiddenUWSGIRequest. UNIX socket connections bypass the IP allowlist entirely, and also offer better performance by eliminating TCP overhead. See: https://gunicorn.org/uwsgi/#using-unix-sockets

Why --preload:
Without --preload, each Gunicorn worker independently loads the app and calls get_random_secret_key(), giving every worker a different SECRET_KEY. When a login request is handled by worker A and the next request hits worker B, the SECRET_KEY mismatch causes Django to flush the session → user gets redirected to login on every click. With --preload, the app loads once in the master process before forking, so all workers inherit the same SECRET_KEY via fork(). This doesn't happen with the uWSGI server since it pre-loads by default.

Tested with docker compose -f docker/default.yml up — all containers healthy, http://localhost/ working, admin sessions persisting correctly.

Nice, thanks! I tested it and have some changes that I will push later. You can consider your work done, good job!

Hi @regulartim , Thanks! Glad to hear it's working well!

Yeah, I also thought about this. I would prefer to do that in a separate issue / PR though (feel free to open an issue). I am a bit scared that such a change might break existing instance.

I’ll do some more research on the non-root users topic, and if it looks like a worthwhile improvement, I’ll open a separate issue for it then we can discuss about it!

I’ll do some more research on the non-root users topic, and if it looks like a worthwhile improvement, I’ll open a separate issue for it then we can discuss about it!

Cool, thank you!