Introduction
Actually, this article is showing how to correct a syntax usage on using gunicorn. There is a requirement to start Django application using gunicorn. So, the following is an actual gunicorn service execution where it ends in a failure. The following is the status of the gunicorn service after failing on to start :
[root@localhost ~]# systemctl status gunicorn ● gunicorn.service - gunicorn daemon Loaded: loaded (/usr/lib/systemd/system/gunicorn.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Thu 2021-11-18 02:43:05 UTC; 4s ago Process: 8821 ExecStart=/home/django/env/bin/gunicorn --access-logfile --workers 3 --bind unix:/home/django/apps.sock apps.wsgi:application (code=exited, status=2) Main PID: 8821 (code=exited, status=2) Nov 18 02:43:05 localhost systemd[1]: Started gunicorn daemon. Nov 18 02:43:05 localhost gunicorn[8821]: usage: gunicorn [OPTIONS] [APP_MODULE] Nov 18 02:43:05 localhost gunicorn[8821]: gunicorn: error: argument --access-logfile: expected one argument Nov 18 02:43:05 localhost systemd[1]: gunicorn.service: main process exited, code=exited, status=2/INVALIDARGUMENT Nov 18 02:43:05 localhost systemd[1]: Unit gunicorn.service entered failed state. Nov 18 02:43:05 localhost systemd[1]: gunicorn.service failed. [root@localhost ~]#
Basically, there is a service script file for gunicorn to run the Django application. Before going on to the solution, the following is the actual content of the ‘gunicorn.service’ file :
[Unit] Description=gunicorn daemon After=network.target [Service] User=django Group=nginx WorkingDirectory=/home/django/myapps ExecStart=/home/django/env/bin/gunicorn --access-logfile --workers 3 --bind unix:/home/django/apps.sock apps.wsgi:application [Install] WantedBy=multi-user.target
Solution
Actually, the solution is very simple. It is only a matter of the gunicorn command pattern execution. In the gunicorn service script above, the following are the command execution of gunicorn :
/home/django/env/bin/gunicorn --access-logfile --workers 3 --bind unix:/home/django/apps.sock apps.wsgi:application
After executing it in the command line, it generates an error message. It is appear as in the gunicorn service status as follows :
gunicorn: error: argument --access-logfile: expected one argument
The solution is just by solving the gunicorn command pattern by revising the above command pattern as follows :
/home/django/env/bin/gunicorn --access-logfile - --workers 3 --bind unix:/home/django/apps.sock apps.wsgi:application
The point is in the following part :
--access-logfile --workers 3
into the following part :
--access-logfile - --workers 3
The new line will define the value of the parameter
--access-logfile
as
-
rather than not even define it as in the old line.