Демонизация приложений, делаем демон приложения в CentOS (Debian), работа с сервисами

Все управляющие программы для роботов по сути демоны/службы - работают в бесконечном цикле.

В CentOS, в отличии от Ubuntu, по умолчанию нет Start-stop-daemon для запуска своих процессов в виде демонов. При его наличии запуск приложения в виде демона решается простой командой (главное чтобы скрипт был исполняемым :)).

start-stop-daemon -Sbvx /home/redkin_p/bin/test.rb

Для того чтобы сделать это в CentOS (справедливо и для Debian) есть такие варианты:

0) Запустить приложение через nohup. Или в сессии screen/tmux (о screen).

nohup — UNIX-утилита, запускающая указанную команду с игнорированием сигналов потери связи (SIGHUP). Таким образом, команда будет продолжать выполняться в фоновом режиме и после того, как пользователь выйдет из системы.
Позволяет не запускать start-stop-daemon, делать сервисы и вообще что-либо. Идет из коробки во всех известных дистрибутивах Linux. Еще круто, что вывод она пишет в отдельный файл - nohup.out (если не нужен - можно дропнуть через редирект &>/dev/null)

nohup bin/sms2.rb
nohup nmap -sP 10.3.0.0/20
nohup ip netns exec VRF1 ping 172.17.0.2 >ping_res_va # по умолчанию STDOUT сохраняется в файле nohup.out

1) собрать start-stop-daemon для CentOS. Как по мне очень плохое решение (но, возможно, в 2011 единственное) – требует компилятора, компиляции и прочих штук очень долгих и несущих существенные изменений в систему (зависимые системные библиотеки).

2) Сделать сервис в system.d. Прекрасное и самое правильное решение. Немного сложнее start-stop-daemon (и, тем более, nohup), но лучше т.к. позволяет стандартно добавить сервис в автозагрузку, следить по аналогии с другими сервисами за работоспособностью, стандартно перезагружать и прочее.

https://scottlinux.com/2014/12/08/how-to-create-a-systemd-service-in-linux-centos-7/ 
https://unix.stackexchange.com/questions/236084/how-do-i-create-a-service-for-a-shell-script-so-i-can-start-and-stop-it-like-a-d
Пошагово создание сервиса в system.d

1) Создаем файл с сервисом, называем как хотим, на конце должно быть “service”.

$ cat /etc/systemd/system/test_service.service 
[Unit] 
Description=test_service.rb

[Service] 
Type=simple 
ExecStart=/usr/bin/test_service.rb

[Install] 
WantedBy=multi-user.target

Для передачи переменных (напр. указываем название файла вывода от времени запуска сервиса) можно вызывать утилиту через /bin/bash. Пример: запускаем tcpdump, имя файла с дампом содержит дату/время запуска.

ExecStart=/bin/bash -c "test=$(/usr/bin/date | tr ' :' '.'); /usr/sbin/tcpdump -n -w /opt/logs/$test.pcap"

2) Перезагружаем службу демонов

sudo systemctl daemon-reload

3) Стартуем наш сервис

sudo systemctl start test_service

4) Проверяем статус. Тут так же видим последние сообщения от нашей программы/скрипта. Для просмотра всех сообщений смотрим journalctl.

sudo systemctl status test_service
sudo journalctl -u test_service

5) Добавляем в автозагрузку (можно так же использовать множество других способов, напр. добавив команду start сервиса в /etc/rc.local, но самый правильный через systemctl; offtop: при использовании rc.local нужно не забывать добавлять shebang и права на исполнение)

sudo systemctl enable test_service

Enjoy

 

Типы сервисов в system.d

Выше рассмотрен простой типовой случай, когда используется тип сервиса simple, но возможно так же использовать oneshot и forking.

  • Forking: systemd считает службу запущенной после того, как процесс разветвляется с завершением родительского процесса. Нужен для работы с приложениями, которые создают дочерние процессы при запуске (напр. worker’ы), а сами при этом отключаются – используется для запуска классических демонов за исключением тех случаев, когда в таком поведении процесса нет необходимости. Можно указать параметр PIDFile=, чтобы systemd мог отслеживать основной процесс. Oneshot и forking для таких задач подходят плохо, они оба предназначены для работы именно с тем процессом, который запускается
Both Type=oneshot and Type=simple units ignore any children of the first process, so do not use these modes with forking processes
  • Simple (по умолчанию): systemd запустит эту службу незамедлительно. Процесс при этом не должен разветвляться (fork). Если после данной службы должны запускаться другие, то этот тип использовать не стоит (исключение — служба использует сокетную активацию).
  • Oneshot: удобен для сценариев, которые выполняют одно задание и завершаются. Примеры использования.
Если задать параметр RemainAfterExit=yes, то systemd будет считать процесс активным даже после его завершения.

Leave a Reply