Команда `sudo systemctl start mybig_app` держится, а служба стоит в статусе loaded(activating), никогда не переходя в active

Я разработал довольно большое приложение на django.

Я развернул его по пути /var/www/mybig_app/ на серверной машине (raspberry pi), подключенной к моей локальной сети.

Приложение использует библиотеки, хранящиеся в виртуальной среде /var/www/mybig_app/venv/.

Я настроил .wsgi файл, чтобы проинструктировать gunicorn выставить приложение на порт 8003 localhost и nginx для передачи содержимого с порта 8003 на порт 3003.

Итак, с текущим каталогом /var/www/mybig_app/, я запускаю

python manage.py runserver localhost:8003

или

/var/www/mybig_app/venv/bin/gunicorn mybig_app.wsgi:application --bind localhost:8003

и даже если мне приходится ждать около 5 секунд, в обоих случаях я могу зайти в приложение через браузер другого устройства, подключенного к локальной сети по адресу localhost:8003 (я пробовал войти как администратор, зайти на все страницы, все работает, ошибок нет).

Теперь я хочу управлять своим приложением как сервисом через systemd.

Итак, я подготовил файл .service по адресу /var/www/mybig_app/infrastructure/systemd/mybig_app.service, симболически связанный с

ln -s /var/www/mybig_app/infrastructure/systemd/mybig_app.service /etc/systemd/system/
ln -s /var/www/mybig_app/infrastructure/systemd/mybig_app.service /etc/systemd/system/multi-user.target.wants/

загрузил конфигурацию для systemd

sudo systemctl daemon-reload
sudo systemctl enable mybig_app.service

(я делал это раньше для других приложений, это работает)

В конце концов я хочу запустить его, но когда из каталога /var/www/mybig_app я запускаю

sudo systemctl start mybig_app.service

Я получаю команду, удерживая ее, после достижения установленного мной 15-секундного тайм-аута, и получаю

Job for mybig_app.service failed because a timeout was exceeded.
See "systemctl status mybig_app.service" and "journalctl -xe" for details.

Так что я бегу

journalctl -xe

и я вижу

-- 
-- A stop job for unit mybig_app.service has finished.
-- 
-- The job identifier is 20135 and the job result is done.
May 08 17:48:02 Raspberry100 systemd[1]: Starting service for starting the app mybig_app on RPi...
-- Subject: A start job for unit mybig_app.service has begun execution
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit mybig_app.service has begun execution.
-- 
-- The job identifier is 20135.
May 08 17:48:05 Raspberry100 sudo[1806]:     root : TTY=pts/1 ; PWD=/var/www/mybig_app ; USER=root ; COMMAND=/bin/systemctl daemon-reload
May 08 17:48:05 Raspberry100 sudo[1806]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
May 08 17:48:05 Raspberry100 systemd[1]: Reloading.
May 08 17:48:05 Raspberry100 sudo[1806]: pam_unix(sudo:session): session closed for user root
May 08 17:48:09 Raspberry100 sudo[1838]:     root : TTY=pts/1 ; PWD=/var/www/mybig_app ; USER=root ; COMMAND=/bin/systemctl start mybig_app.
May 08 17:48:09 Raspberry100 sudo[1838]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
May 08 17:48:18 Raspberry100 systemd[1]: mybig_app.service: Start operation timed out. Terminating.
May 08 17:48:18 Raspberry100 systemd[1]: mybig_app.service: Failed with result 'timeout'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit mybig_app.service has entered the 'failed' state with result 'timeout'.
May 08 17:48:18 Raspberry100 systemd[1]: Failed to start service for starting the app mybig_app on RPi.
-- Subject: A start job for unit mybig_app.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- A start job for unit mybig_app.service has finished with a failure.
-- 
-- The job identifier is 20135 and the job result is failed.
May 08 17:48:18 Raspberry100 sudo[1838]: pam_unix(sudo:session): session closed for user root

В чем здесь проблема?

мои гипотезы

Я думаю, что это как-то связано с содержимым моего mybig_app.service файла, но я использовал ту же процедуру и то же самое для других приложений в прошлом, просто изменив имя проекта, и это всегда работало.

Еще одна проблема может заключаться в установленных библиотеках, которые довольно старые (проект 2018 года).

Обратите внимание, что поскольку приложению потребовалось несколько секунд (не более 5) на настройку, так как я запускал его через python и gunicorn, в моем файле .service я установил

[Service]
...

# RestartSec=100ms # this is the default
RestartSec=15s
TimeoutStartSec=15s
TimeoutSec=15s

для того, чтобы дать ему больше времени на настройку (по умолчанию таймаут перезапуска составляет 0,1 секунды).

Что я пробовал

Я удалил и заново создал виртуальную среду.

Я перезагрузил серверную машину.

Я попытался увеличить таймаут до 115 секунд.

Отладка

Я заметил, что при выполнении команды запуска, я могу зайти в свое приложение через браузер другого устройства, подключенного к моей локальной сети.

Симилитуды с другими вопросами СЦ

Проблема похожа на эту, поскольку я не могу запустить или перезапустить свое приложение как службу, но я могу успешно запустить его через python или gunicorn. Однако в моем случае я использую в качестве веб-сервера не httpd, а nginx, который прекрасно работает для других приложений, настроенных таким же образом.

содержимое файлов

mybig_app.service

[Unit]
# the first line must be 
# [Unit]

#------------------------------------------------------------------------

# what to do with this file

# this file must be named
# <target_app>.service
# and deployed to
# /etc/systemd/system 
# to be ran on boot.

# Once in the folder make the file executable 
# sudo chmod +x <target_app>.service

# This will start the service but will not run it on boot.
# sudo systemctl start <target_app>.service

# To make your service automatically run on boot
# sudo systemctl daemon-reload
# sudo systemctl enable <target_app>.service

# Run this in terminal to disable the program on boot
# sudo systemctl daemon-reload
# sudo systemctl disable <target_app>.service

# Documentation https://www.freedesktop.org/software/systemd/man/systemd.service.html

#------------------------------------------------------------------------

Description=service for starting the app mybig_app on RPi

After=network.target
# This will not start execution of this file until the network connection is made
# It can be replaced with other parameters of your choosing
# e.g.
# After=syslog.target


[Service]
WorkingDirectory=/var/www/mybig_app/
ExecStart=/var/www/mybig_app/venv/bin/gunicorn mybig_app.wsgi:application --bind localhost:8003

StandardOutput=file:/var/log/mybig_app/mybig_app-stdout.log
StandardError=file:/var/log/mybig_app/mybig_app-stderr.log
#Optional: Saves the output and error log of the terminal to a .log file in a directory of your choosing.

Restart=always
# Automatically restart on kill

# RestartSec=100ms # this is the default
RestartSec=15s
TimeoutStartSec=15s
TimeoutSec=15s

KillSignal=SIGQUIT
# Optional: To cleanly end the file on stop use this command. This sends a terminal interrupt command on the executable script
# alternatively:
# Restart=on-failure

Type=notify
NotifyAccess=all


[Install]
WantedBy=multi-user.target

Я думаю, что проблема в том, что systemd не знает, что служба запущена, я думаю, что вы должны сделать server.Type=exec как указано в systemd help

При использовании Type=notify systemd ожидает уведомления от службы через sd_notify, поддержка этого была добавлена в Gunicorn только в версии 20.0 (см. следующий комментарий к проблеме на GitHub).

Если вы хотите использовать Type=notify, вам следует обновить версию Gunicorn, в противном случае вы можете просто установить Type=exec.

Вернуться на верх