Вопросы Теги

Главный процесс завершен, код = exited, status = 7 / NOTRUNNING

У меня есть приложение узла, работающее через службу systemd в Ubuntu 16.04

Однако через некоторое время служба автоматически перезапускается.

Вот что я получаю в журналах: 

Mar 17 14:35:10 testmachine systemd[1]: myService.service: Main process exited, code=exited, status=7/NOTRUNNING
Mar 17 14:35:10 testmachine systemd[1]: myService.service: Unit entered failed state.
Mar 17 14:35:10 testmachine systemd[1]: myService.service: Failed with result 'exit-code'.
Mar 17 14:35:40 testmachine systemd[1]: myService.service: Service hold-off time over, scheduling restart.

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

myService.service 

[Unit]
Description=The will start node app
After=cleanMongo.service

[Service]
ExecStart=/media/path/to/execution/scriptFile
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

Но моя проблема в том, почему он думает, что служба не запущена? Приложение делает свое дело, и в середине оно перезапускается.

PS: У меня много заданий CRON, запущенных в приложении узла, это тот случай, когда процесс слишком занят, чтобы отвечать на какие-то isAlive из systemd? И поэтому systemd считает, что он не работает?

0
задан 21 March 2017 в 11:18
2 ответа

Во-первых, я не эксперт по nodejs.

Как говорили другие, вам следует как можно больше перейти к модулю systemd. cd может быть заменен на WorkingDirectory sudo бесполезен, но может быть заменен на User , а переменная среды может быть установлена ​​на Environment .

Systemd не ожидает вызова isAlive от вашего демона, если Тип is! = notify (по умолчанию простой )

NOTRUNNING - это интерпретация кода выхода вашего процесса, это означает, что процесс вашего узла завершается с кодом ошибки 7 Документ узла говорит, что код выхода означает «Произошло неперехваченное исключение, и сама функция внутреннего фатального обработчика исключений вызвала ошибку при попытке ее обработать. " поэтому должен быть какой-то вывод в журнале или месте назначения журнала nodejs.

0
ответ дан 4 December 2019 в 16:19

Обычно systemd/ systemctl сообщает о сбое в запуске (если/когда вы запускаете sudo systemctl, запустите myService.service).

Я проверяю:

  • выходной сигнал sudo systemctl статуса myService. service
  • вывод sudo journalctl -ln 2000 -u myService

Вывод любого из них может помочь в диагностике проблемы (journalctl может быть лучшей ставкой).

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

systemd/systemctl фактически отслеживает PID, поэтому опрос не должен быть проблемой.

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

Ваша конфигурация systemd ожидает, что сможет отследить сам процесс по PID. Однако, она 'увидит' PID скрипта, но, в зависимости от того, как вы запустите узел из этого скрипта, она может быть не в состоянии отследить PID узла.

Похоже, что более надежным подходом было бы прямое выполнение узла (как предлагалось здесь):

[Unit]
Description=Node.js Example Server
#Requires=After=mysql.service       # Requires the mysql service to run first

[Service]
ExecStart=/usr/local/bin/node /opt/nodeserver/server.js
#WorkingDirectory=/opt/nodeserver   # Required on some systems
Restart=always
RestartSec=10                       # Restart service after 10 seconds if node service crashes
StandardOutput=syslog               # Output to syslog
StandardError=syslog                # Output to syslog
SyslogIdentifier=nodejs-example
#User=<alternate user>
#Group=<alternate group>
Environment=NODE_ENV=production PORT=1337

[Install]
WantedBy=multi-user.target

Таким образом, systemd может отследить правильный PID.

Если вам нужно выполнить некоторые команды перед запуском узла, рассмотрите возможность использования systemd ExecStartPre.

Существует ряд других опций, предоставляемых systemd (см. страницу руководства Unit file), которые позволяют избежать использования обертки:

  • , как уже упоминалось, ExecStartPre позволяет выполнять задачи до запуска основного процесса (а ExecStartPost для выполнения задач после)
  • можно выражать зависимости от других служб с помощью Require, Хочет , До и После , а также можно использовать Конфликты или различные ключевые слова Состояние* .
1
ответ дан 4 December 2019 в 16:19

Теги

Похожие вопросы