9👍
The problem may lie with your userid attempting to start the process as another user. I’m assuming you’ve created the user and group in the OS. You could try your previous command as root or use sudo
.
I use the following Supervisor configuration which specifies the user on both the command line and as an option:
[program:gunicorn]
command=/opt/mysite/virtual_env/bin/python \
/opt/mysite/virtual_env/bin/gunicorn_django -w 2 --user=appsrun
directory = /opt/mysite/virtual_env/app/
user = appsrun
0👍
One workaround for this problem is to change the user and group IDs with which gunicorn
is run to match the system (or container) UID and GID:
$ gunicorn --user $(id -u) --group $(id -g) [..] app:app
One scenario when this happens is when you start a python app with gunicorn
when --group
is set to 0, or any other value different from the one used in the folder where gunicorn
was installed (as it seems to attempt to write its temporary files in its current runtime/installation folder, rather than the /tmp
it shows in its error message).
Strangely this apparent gunicorn
bug persists even today (6 years later, under the latest stable versions of Python (3.11), Ubuntu (22.04 LTS) and gunicorn
(20.1.0)). Django is not involved (this issue happens also with Flask).