Вы должны запустить строк
в своей программе:
strings /path/to/binary
Это выведет все строки (по умолчанию) из 4 или более печатаемых символов подряд на ваш терминал. Многое из этого будет мусором, но , если имя хоста действительно находится где-то в двоичном файле, это должно вам сказать.
Я согласен с вами, что очень маловероятно, что он будет содержать такие вещи, как MAC-адрес или имя хоста компилирующего хоста; однако, если двоичный файл не разделен (т.е. содержит символы отладки), он, вероятно, все равно будет содержать имена путей к источнику, из которого он был скомпилирован. Это может дать вам некоторое представление о том, в какой среде он был создан.
Чтобы расширить комментарий 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
.
daemontools Дэна Бернштейна был разработан для сделали это и создали целое семейство наборов инструментов, которые используют одни и те же необработанные механизмы:
Практически под любой из них можно написать программу run
, которая запускает / является демоном, и диспетчер служб или процесс супервизора просто контролирует его как разветвленный дочерний процесс, используя обычные механизмы Unix и Linux. Это может быть сделано либо в масштабе всей системы с помощью специального диспетчера служб, запущенного от имени суперпользователя, либо для каждого пользователя с отдельными диспетчерами служб.
Все эти наборы инструментов согласованы и самосогласованы, но обратите внимание, что ни один из них не требует использования каких-либо инструментов, кроме тех, которые необходимы в той или иной конкретной ситуации. Можно также смешивать и сочетать. Можно использовать execlineb
Лорана Беркота и все его утилиты под perp или мой nosh
интерпретатор скриптов и все его утилиты под runit; точно так же, как можно использовать chpst
Геррита Пейпа под моим сервис-менеджером
.
Точно так же вы можете использовать общесистемную или индивидуальную службу, запускаемую из systemd. Модульные файлы systemd имеют тот же порядок простоты, что и сценарии run
, хотя, будучи необязательными, они не обеспечивают точного точного контроля над тем, как устанавливается состояние выполнения процесса службы. Конечно, это 2017 год, и применяется первое правило перехода на systemd .
Все они обеспечивают базовую основу для запуска демона при начальной загрузке, его остановки и запуска под административным / автоматическим управлением во время работы системы и автоматического перезапуска в различных случаях сбоя.