У меня проблемы с настройкой Gunicorn. Пока что я вытащил свой код django на сервер, создал virtualenv для python3.6, установил django gunicorn psycop2, используя pip3, и все в порядке.
Я могу запустить сервер разработки django и увидеть мой нестилизованный сайт и успешно разместить его в базе данных через сайт администратора, так что все работает. Затем я запустил его напрямую, используя:
gunicorn django_version.wsgi:application --bind 10.88.58.95:80
и снова смог увидеть мой нестилизованный сайт. Я также пробовал:
/srv/pcc_django/django_env/bin/gunicorn --workers 3 --bind unix:/srv/pcc_django/django_version/django_version.sock django_version.wsgi:application
и это началось без ошибок. Итак, моим следующим шагом было написать файл .service:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=user
Group=nginx
WorkingDirectory=/srv/pcc_django
ExecStart=/srv/pcc_django/django_env/bin/gunicorn --workers 3 --bind unix:/srv/pcc_django/django_version/django_version.sock django_version.wsgi:application
[Install]
WantedBy=multi-user.target
и пытаюсь:
systemctl start gunicorn.service
Я получаю сообщение об ошибке выше, в котором говорится:
systemctl status gunicorn.service
и там следующее сообщение:
● gunicorn.service - gunicorn daemon
Loaded: error (Reason: Bad message)
Active: inactive (dead) since Thu 2019-10-17 08:39:02 UTC; 3h 16min ago
Main PID: 29080 (code=exited, status=0/SUCCESS)
Oct 16 16:24:08 pcc-home-page.novalocal gunicorn[29080]: [2019-10-16 16:24:08 +0000] [29085] [INFO] Booting worker with pid: 29085
Oct 16 16:24:08 pcc-home-page.novalocal gunicorn[29080]: [2019-10-16 16:24:08 +0000] [29086] [INFO] Booting worker with pid: 29086
Oct 17 08:39:02 pcc-home-page.novalocal systemd[1]: Stopping gunicorn daemon...
Oct 17 08:39:02 pcc-home-page.novalocal gunicorn[29080]: [2019-10-17 08:39:02 +0000] [29084] [INFO] Worker exiting (pid: 29084)
Oct 17 08:39:02 pcc-home-page.novalocal gunicorn[29080]: [2019-10-17 08:39:02 +0000] [29080] [INFO] Handling signal: term
Oct 17 08:39:02 pcc-home-page.novalocal gunicorn[29080]: [2019-10-17 08:39:02 +0000] [29085] [INFO] Worker exiting (pid: 29085)
Oct 17 08:39:02 pcc-home-page.novalocal gunicorn[29080]: [2019-10-17 08:39:02 +0000] [29086] [INFO] Worker exiting (pid: 29086)
Oct 17 08:39:02 pcc-home-page.novalocal gunicorn[29080]: [2019-10-17 08:39:02 +0000] [29080] [INFO] Shutting down: Master
Oct 17 08:39:02 pcc-home-page.novalocal systemd[1]: Stopped gunicorn daemon.
Oct 17 08:39:14 pcc-home-page.novalocal systemd[1]: [/etc/systemd/system/gunicorn.service:12] Missing '='.
но происходит что-то странное, потому что если я это сделаю:
date +%H:%M:%S.%N
Я получаю следующую метку времени:
11.57.13.124995238
Поэтому я не уверен, что это сообщение связано с некорректным запуском службы Gunicorn. Что я пропустил, что мешает запуску Gunicorn как службы?
Проблема в том, что у меня не было файла gunicorn.socket, и он был в служебном файле как Required. Добавление следующего файла в ту же папку, что и служебный файл:
/etc/systemd/system/
Gunicorn.socket
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=multi-user.target
Исправлена первая часть проблем, затем исправлено расположение файла .sock в файле .service (выше в исходном сообщении), и, наконец, я также добавил shebang вверху служебного файла. Изменения находятся в строке 1 вверху и в середине строки 11 в разделе [Service]:
#!/bin/sh
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=user
Group=nginx
WorkingDirectory=/srv/pcc_django
ExecStart=/srv/pcc_django/django_env/bin/gunicorn --workers 3 --bind unix:/run/gunicorn.sock django_version.wsgi:application
[Install]
WantedBy=multi-user.target
Также убедитесь, что файл .sock имеет одинаковое название. Я назвал его "gunicorn.socket", поэтому в путях он называется "gunicorn.sock" в большинстве учебных пособий, они имеют его как:
project_name.sock
и поместил его в корневую папку проекта, а также люди, упоминающие, что вставлять его вместе с вашим кодом - это проблема безопасности, я просто обнаружил, что стало сложно узнать, что файл был вызван по сравнению с тем, где он был. Поэтому называть его gunicorn.socket для меня имеет больше смысла, и это легко увидеть в интерфейсе командной строки, поскольку он не путается с путями к файлам.