UWSGI SIGINT/SIGQUIT получен

Вопрос или проблема

Я пытаюсь использовать nginx с uwsgi.

Я написал ini файл для uwsgi и протестировал его с помощью uwsgi –ini site.ini

Все работает нормально.

Но когда я пытаюсь запустить сайт, я получаю следующую ошибку (из файла журнала):

*** Поддержка Python потоков отключена. Вы можете включить ее с помощью --enable-threads$
Python главный интерпретатор инициализирован при 0x1a297d0
ваша серверная очередь ожидания ограничена 100 соединениями
ваше милосердие для плавных операций на рабочих 60 секунд
отображено 800360 байт (781 КБ) для 10 ядер
*** Операционный РЕЖИМ: preforking ***
WSGI приложение 0 (точка монтирования="") готово за 0 секунд на интерпретаторе 0x1a297d0 pid: 177$
*** uWSGI работает в режиме нескольких интерпретаторов ***
создан uWSGI главный процесс (pid: 17715)
создан uWSGI рабочий 1 (pid: 17718, ядра: 1)
создан uWSGI рабочий 2 (pid: 17719, ядра: 1)
создан uWSGI рабочий 3 (pid: 17720, ядра: 1)
создан uWSGI рабочий 4 (pid: 17721, ядра: 1)
создан uWSGI рабочий 5 (pid: 17722, ядра: 1)
создан uWSGI рабочий 6 (pid: 17723, ядра: 1)
создан uWSGI рабочий 7 (pid: 17724, ядра: 1)
создан uWSGI рабочий 8 (pid: 17725, ядра: 1)
создан uWSGI рабочий 9 (pid: 17726, ядра: 1)
получен SIGINT/SIGQUIT... остановка рабочих...
рабочий 1 похоронен через 1 секунду
рабочий 2 похоронен через 1 секунду
рабочий 3 похоронен через 1 секунду
рабочий 4 похоронен через 1 секунду
рабочий 5 похоронен через 1 секунду
рабочий 6 похоронен через 1 секунду
рабочий 7 похоронен через 1 секунду
рабочий 8 похоронен через 1 секунду

Почему я получаю SIGINT автоматически?

Вот несколько идей, которые можно попробовать:

  1. Проблема с конфигурацией службы systemd: Если вы используете systemd для управления uWSGI, он может быть настроен на слишком агрессивный перезапуск службы или с неправильными параметрами.

  2. Несоответствие конфигурации nginx: Возможно, есть несоответствие сокета/порта между конфигурациями nginx и uWSGI.

  3. Другой процесс контролирует uWSGI: Что-то еще может управлять процессом uWSGI (например, supervisor) и завершать его.

  4. Конфликты портов: uWSGI может пытаться занять порт, который уже используется.

  5. Управление процессом: Если вы запускаете uWSGI непосредственно в терминале и затем закрываете этот терминал, он отправит SIGINT процессу.

Для устранения неполадок:

  1. Проверьте, как вы запускаете uWSGI:

    • Запускаете ли вы его напрямую в терминале, который закрываете?
    • Используете ли вы systemd, supervisor или другой диспетчер процессов?
  2. Проверьте ваши конфигурации:

    # Проверьте ваш файл site.ini
    cat site.ini
    
    # Проверьте вашу конфигурацию nginx
    cat /etc/nginx/sites-enabled/yoursite
    
  3. Запустите uWSGI в фоновом режиме с более подробным ведением журнала:

    uwsgi --ini site.ini --master-as-root --enable-threads --log-master --log-5xx
    
  4. Ищите конфликты портов:

    sudo netstat -tulpn | grep <port_number>
    

Вы также можете поделиться своей конфигурацией uWSGI (site.ini) и связанной конфигурацией nginx. Это может помочь точно определить проблему.

Ответ или решение

Теория

Получение сигналов SIGINT или SIGQUIT на сервере uWSGI может произойти по многим причинам. Эти сигналы, как правило, предназначены для завершения процесса. SIGINT обычно генерируется клавишной комбинацией (например, Ctrl+C в терминале), а SIGQUIT может сигнализировать о потребности в экстренном завершении программы. Эти сигналы могут быть отправлены процессу uWSGI в результате ошибок конфигурации, конфликта портов, проблем с процессами или неправильно настроенных средств управления сервисами, таких как systemd или supervisor.

Пример

В представленном лог-файле указывается, что uWSGI запускается и создает несколько рабочих процессов, но сразу после этого получает сигнал SIGINT/SIGQUIT и завершает работу. Это может указывать на несколько возможных проблем:

  1. Конфигурация systemd или других средств управления: Если uWSGI управляется systemd или supervisor, возможны ошибки в конфигурации, которые приводят к повторному запуску или завершению сервиса.

  2. Конфликт портов: Если uWSGI пытается занять порт, который уже используется другим процессом, это может привести к получению сигнала завершения.

  3. Неверная конфигурация Nginx-uWSGI: Ошибки в настройках могут привести к тому, что подключения отклоняются, что, в свою очередь, может вызвать завершение процессов uWSGI.

  4. Запуск в терминале: Если uWSGI запускается напрямую в терминале, закрытие терминала или сессии может отправить сигнал SIGINT.

Применение

Чтобы решить проблему, необходимо выполнить несколько шагов:

  1. Проверка способа запуска uWSGI:

    • Запустите процесс через терминал, чтобы избежать закрытия сессии;
    • Если используется systemd, проверьте конфиги и логи через команды sudo systemctl status <имя_сервиса> и journalctl -xe.
  2. Анализ конфигурационных файлов:

    • Проверьте ваш файл конфигурации uWSGI (site.ini) и убедитесь, что все параметры корректно указаны.
    • Перепроверьте конфигурацию Nginx в части взаимодействия с uWSGI, особенно пути и адреса сокетов.
  3. Запуск uWSGI с подробным логированием:

    • Используйте дополнительные параметры для логирования: uwsgi --ini site.ini --master-as-root --enable-threads --log-master --log-5xx.
    • Это поможет отследить ошибки на уровне взаимодействия с различными компонентами.
  4. Исключение конфликтов портов:

    • Выполните команду sudo netstat -tulpn | grep <port_number>, чтобы определить, не используется ли указанный порт другим процессом.
  5. Удаление других управляемых процессов:

    • Убедитесь, что ни один другой процесс (например, Supervisor) не отправляет сигналы uWSGI. Для этого проверьте конфигурации всех возможных менеджеров процессов.

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

Таким образом, следуя этим рекомендациям и внимательно проверяя настройки, можно обнаружить и, следовательно, устранить источник возникновения автоматического получения сигнала SIGINT в сервере uWSGI, обеспечивая стабильную и надежную работу вашего веб-приложения.

Оцените материал
Добавить комментарий

Капча загружается...