PM2 говорит, что исполняемый файл «ошибся», но не перезапускает его должным образом; нужно еще перезагрузить вручную - PullRequest
0 голосов
/ 04 апреля 2020

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

Когда mongod аварийно завершает работу или становится неотвечая, pm2 правильно устанавливает свой статус «с ошибкой», и я считаю, что он пытается перезапустить его «изнутри». Количество перезапусков увеличивается до абсурдных чисел. Просто тот автоматический перезапуск не восстанавливает mongod по какой-то причине.

$ pm2 describe 0

Describing process with id 0 - name mongod 
┌───────────────────┬──────────────────────────────────────────────────────┐
│ status            │ errored                                              │
│ name              │ mongod                                               │
│ namespace         │ default                                              │
│ version           │ N/A                                                  │
│ restarts          │ 2931682                                              │
│ uptime            │ 0                                                    │
│ script path       │ /usr/bin/bash                                        │
│ script args       │ -c mongod --verbose --config /etc/mongod.conf --auth │
│ error log path    │ /root/.pm2/logs/mongod-error.log                     │
│ out log path      │ /root/.pm2/logs/mongod-out.log                       │
│ pid path          │ /root/.pm2/pids/mongod-0.pid                         │
│ interpreter       │ none                                                 │
│ interpreter args  │ N/A                                                  │
│ script id         │ 0                                                    │
│ exec cwd          │ /var/www/nodeapi                                     │
│ exec mode         │ fork_mode                                            │
│ node.js version   │ N/A                                                  │
│ node env          │ N/A                                                  │
│ watch & reload    │ ✘                                                    │
│ unstable restarts │ 0                                                    │
│ created at        │ N/A                                                  │
└───────────────────┴──────────────────────────────────────────────────────┘

В этом состоянии я все еще могу успешно восстановить mon go, используя pm2, но только с помощью команды restart вручную:

$ pm2 restart 0

Мой первый вопрос: что делает ручной перезапуск делает то, что автомат c один не делает? Почему мой ручной перезапуск преуспевает в воскрешении mongod, но ни один из показанных автоматических перезапусков c 2931682 не удался?

В качестве альтернативы, возможно, mongod вообще не взломал sh, но pm2 просто ДУМАЕТ, что он разбился и переходит в безумный перезапуск l oop.

Итак, мой второй вопрос: как pm2 решает, был ли сбой исполняемого файла, который не nodejs, или нет? Возможно, из какой-то эвристики в журнале вытекает, что произошел сбой, и неправильная классификация называет его «ошибочным»?

Я не понимаю, каким образом pm2 может судить о состоянии приложения, которое не ' Само по себе, особенно если это скрипт или бинарный сторонний исполняемый файл. Есть идеи?

1 Ответ

0 голосов
/ 05 апреля 2020

Я обнаружил, что мой конфигурационный файл mon go требует, чтобы mongod разветвлялся при каждом запуске.

Также в журналах mon go указан код выхода 48, что означает, что он не смог запуск из-за того, что IP / порт уже занят, якобы другим работоспособным экземпляром mongod.

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

pm2, кажется, ожидает чего-либо, что начинает блокировать, пока не будет сделано. С принудительной настройкой разветвления в конфиге pm2 утратил контроль над процессом, и последующие запуски привели к коду 48 выхода, потому что, очевидно, предыдущий разветвленный mongod уже работал.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...