Как автоматически перезапустить процесс, когда он был убит в linux / CentOS

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

strings /path/to/binary

Это выведет все строки (по умолчанию) из 4 или более печатаемых символов подряд на ваш терминал. Многое из этого будет мусором, но , если имя хоста действительно находится где-то в двоичном файле, это должно вам сказать.

Я согласен с вами, что очень маловероятно, что он будет содержать такие вещи, как MAC-адрес или имя хоста компилирующего хоста; однако, если двоичный файл не разделен (т.е. содержит символы отладки), он, вероятно, все равно будет содержать имена путей к источнику, из которого он был скомпилирован. Это может дать вам некоторое представление о том, в какой среде он был создан.

5
11.01.2017, 07:16
2 ответа

Чтобы расширить комментарий Ipor Sircer об использовании systemd

Из документации RHEL 7 :

Systemd - это системный и сервисный менеджер для операционных систем Linux.Он разработан для обратной совместимости со сценариями инициализации SysV и предоставляет ряд функций, таких как параллельный запуск системных служб во время загрузки, активация демонов по требованию, поддержка моментальных снимков состояния системы или логика управления службами на основе зависимостей. В Red Hat Enterprise Linux 7 systemd заменяет Upstart в качестве системы инициализации по умолчанию.

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

Служебные файлы принадлежат /etc/systemd/system/NAME.service согласно документации

Пример настраиваемого служебного файла из документации RHEL 7 снова:

[Unit]
Description=service_description
After=network.target

[Service]
ExecStart=path_to_executable
Type=simple

[Install]
WantedBy=default.target

Их описание того, что делает этот файл:

Где:

service_description - информативное описание, которое отображается в файлах журнала журнала и в выводе команды systemctl status.

Параметр «После» гарантирует, что служба запускается только после запуска сети. Добавьте разделенный пробелами список других соответствующих услуг или целей.

path_to_executable обозначает путь к фактическому исполняемому файлу службы.

...

WantedBy указывает цель или цели, под которыми должна быть запущена служба. Думайте об этих целях как о замене старой концепции уровней запуска, подробности см. В Раздел 9.3, «Работа с целями systemd».

Type = simple является нормой и предполагает, что исполняемый файл, запущенный в ExecStart , будет продолжать работать.

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

Еще раз из документации RHEL 7 :

Другой пример - файл конфигурации, который перезапускает службу после выхода ее основного процесса с задержкой в ​​30 секунд:

[Service]
Restart=always
RestartSec=30

Если вы просто добавите Параметр Restart = always в разделе [Служба] вашего служебного файла. Служба должна перезапускаться при каждом отключении / выходе, если вы не остановите ее с помощью systemd .

6
27.01.2020, 20:36

daemontools Дэна Бернштейна был разработан для сделали это и создали целое семейство наборов инструментов, которые используют одни и те же необработанные механизмы:

Практически под любой из них можно написать программу run , которая запускает / является демоном, и диспетчер служб или процесс супервизора просто контролирует его как разветвленный дочерний процесс, используя обычные механизмы Unix и Linux. Это может быть сделано либо в масштабе всей системы с помощью специального диспетчера служб, запущенного от имени суперпользователя, либо для каждого пользователя с отдельными диспетчерами служб.

Все эти наборы инструментов согласованы и самосогласованы, но обратите внимание, что ни один из них не требует использования каких-либо инструментов, кроме тех, которые необходимы в той или иной конкретной ситуации. Можно также смешивать и сочетать. Можно использовать execlineb Лорана Беркота и все его утилиты под perp или мой nosh интерпретатор скриптов и все его утилиты под runit; точно так же, как можно использовать chpst Геррита Пейпа под моим сервис-менеджером .

Точно так же вы можете использовать общесистемную или индивидуальную службу, запускаемую из systemd. Модульные файлы systemd имеют тот же порядок простоты, что и сценарии run , хотя, будучи необязательными, они не обеспечивают точного точного контроля над тем, как устанавливается состояние выполнения процесса службы. Конечно, это 2017 год, и применяется первое правило перехода на systemd .

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

Дополнительная литература

7
27.01.2020, 20:36

Теги

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