systemd: моя служба прекратила работу с кодом=killed

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

Главный PID: 5459 (код=убит, сигнал=TERM)

<...>
systemd[1]: Остановлена служба MyService.

$ /usr/local/bin/ruby bin/rails server -b0.0.0.0 -p 3000 -e production
=> Загрузка Thin
=> Приложение Rails 5.0.1 запускается в производственном режиме на http://0.0.0.0:3000
=> Запустите `rails server -h` для получения дополнительных параметров запуска
[2022-06-21 12:55:32] INFO -- Веб-сервер Thin (v1.8.1 кодовое имя Infinite Smoothie)
[2022-06-21 12:55:32] INFO -- Максимальное количество соединений установлено на 1024
[2022-06-21 12:55:32] INFO -- Слушаем на 0.0.0.0:3000, CTRL+C для остановки
Выход

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

Проблема с остановкой службы в systemd с кодом =killed

Описание проблемы

Вы столкнулись с ситуацией, когда ваша служба, управляемая systemd, неожиданно остановилась, и команда systemctl status возвращает следующее сообщение:

Main PID: 5459 (code=killed, signal=TERM)

Кроме того, просмотр журнала с помощью journalctl -u myservice.service показывает запись:

systemd[1]: Stopped MyService Service.

Анализ сообщения

Символы code=killed, signal=TERM указывают на то, что процесс вашей службы был завершен с помощью сигнала SIGTERM. Этот сигнал часто используется для аккуратной остановки процессов. При этом надо учесть, что такая остановка может быть выполнена как вручную, так и автоматически системой или каким-либо другим процессом.

1. Сигнал TERM:

   • SIGTERM (сигнал 15) — это стандартный сигнал для запроса завершения процесса. Если ваш процесс получает этот сигнал, он должен завершить работу, освобождая ресурсы и завершая свои операции.
   • Если бы процесс завершился аварийно (например, из-за ошибки или исключения), вы бы увидели сообщение, аналогичное code=exited, status=XXX, где XXX — это код завершения.

2. Завершение вручную или аварийное:

   • Вы можете выяснить, кто и почему отправил сигнал TERM, проверяя другие записи в журнале системного журнала ({journalctl}) в момент, предшествующий остановке службы. Возможно, у вас есть другие службы или события (например, OOM Killer — OOM — out of memory), которые могли инициализировать остановку.

Возможные причины

1. Проблемы с ресурсами:

   • Если ваша система испытывает нехватку памяти, Linux может автоматически завершать процессы для освобождения ресурсов. Посмотрите на сообщения OOM Killer с помощью dmesg или проанализируйте журналы системы (например, /var/log/syslog или journalctl -k).

2. Изменение конфигурации:

   • Если изменялась конфигурация системы или самой службы (особенно в контексте управления зависимостями Ruby и gem’ами), это могло повлиять на работу вашего приложения.

3. Отличия в запуске:

   • Запуск программы с ключом -d в командной строке создает процесс в фоновом режиме. Если systemd не удается корректно инициализировать службу для непрерывного выполнения, возможно, будут проблемы с окружением процесса или способами запуска.

Рекомендации по устранению проблемы

1. Проверка журналов:

   • Используйте команду journalctl -xe для анализа событий, предшествующих остановке, чтобы выяснить, не было ли других сигналов о завершении, ошибок или ресурсов, которые могли повлиять на вашу службу.

2. Мониторинг ресурсов:

   • Запустите мониторинг системы, чтобы отслеживать использование памяти и ресурсов. Убедитесь, что у вашего приложения достаточно ресурсов для работы.

3. Проверка конфигурации сервиса:

   • Убедитесь, что конфигурация вашего systemd-сервиса (myservice.service) правильно настроена, особенно секции [Service], ExecStart, и Restart.

4. Окружение и зависимости:

   • Проверьте, не возникла ли проблема с gem’ами или другими зависимостями, которые могли повлиять на запуск вашего сервиса. Если были изменения, попробуйте откатить к прошлой рабочей версии.

5. Логи Rails:

   • Также посмотрите логи вашего приложения Rails, чтобы выяснить, не произошло ли ошибок во время обработки запросов.

Заключение

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