Запустить скрипт в /etc/service (runit) не работает с демоном

Я столкнулся с проблемой со сценарием, через который я начал /etc/service и использует runit,

Мой сценарий в /etc/service/myApp/run похоже:

#!/bin/bash
cd /src
forever -l forever.log -o out.log -e err.log -a start bin/www

Forever запускает мой скрипт как демон. Но это заставляет рунит думать, что мой сервис закончился и работает /etc/service/myApp/run Снова и снова и снова...

Я также попытался запустить это не как демон, и он отлично работает на переднем плане, но у меня все еще есть проблема. У меня есть команда clean-shutdown для отправки на мой сервер в какой-то момент, который в конечном итоге отключит процесс переднего плана, и я не хочу, чтобы он перезапускался. Но, к моему ужасу, /etc/service/myApp/run немедленно вызывается для перезагрузки моего сервера:(

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

РЕДАКТИРОВАТЬ: я обновил свой вопрос, чтобы включить тот факт, что runit используется здесь. Я вижу, что runit контролирует процессы, чтобы поддерживать сервисы. Мой вопрос все еще остается, хотя.

Источник

1 ответ

Решение

Не используйте вечно.

Это очень легко. Как вы уже заметили, здесь навсегда нет необходимости, поскольку runit уже является диспетчером служб и уже запускает и перезапускает вашу программу.

Как вы уже заметили, есть несколько правил для run программы должны делать. Они не должны разветвляться и выходить из основной программы. Менеджер сервисов runit, как и большинство менеджеров сервисов семейства daemontools (существует целое семейство программ, которые работают так), ожидает, что процесс, выполняющий run Программа - это демон. Не его родитель. Не короткое путешествие ночью, которое разветвляется и выходит. Но фактический демон сам.

просто run программа

Существуют различные языки сценариев, которые делают написание таких run программирует пустяк Лоран Берко execline это один. мой nosh Программа другая. Предполагая, что bin/www это исполняемая программа для вашего демона, нош run скрипт будет выглядеть примерно так:

 #! / Bin / перекус
fdmove -c 2 1
chdir / src
бен / WWW

Сценарий execline такой же краткий. Но сценарий оболочки не так много дольше. Если твой run Программа - это сценарий оболочки, и нужно помнить, что программа-оболочка должна быть наложена на программу dæmon в том же процессе. Команда оболочки для этого exec и сценарий оболочки, таким образом, выглядит примерно так:

 #! / bin / sh -e
Exec 2>&1
CD / SRC
exec bin/www

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

Несколько человек собрали и опубликовали run программы, на протяжении многих лет, и большинство run программы такие короткие и простые. Так как у вас есть runit, вы можете начать с собственной коллекции Gerrit Pape run программы.

запуск и остановка демонов

Когда речь заходит о запуске и остановке службы, большинству администраторов служб семейства daemontools снова нужно запретить автоматический перезапуск службы. Все они приходят с инструментом для этого. Вам просто нужно использовать его в своем clean-shutdown скрипт.

  • Рунит имеет sv программа: sv down /etc/service/MyApp
  • S6 имеет s6-svc программа: s6-svc -d /etc/service/MyApp
  • преступник имеет perpctl программа: perpctl d /etc/service/MyApp
  • daemontools имеет svc программа: svc -d /etc/service/MyApp
  • daemontools-бис имеет svc программа: svc -d /etc/service/MyApp
  • у Ноша есть service-control программа: service-control --down /etc/service/MyApp который также называется как svc: svc -d /etc/service/MyApp

Я сказал, что это семейство наборов инструментов. Фактически, под прикрытием все эти инструменты говорят в основном по одному и тому же протоколу.

Это подводит меня к большему вопросу. Все эти наборы инструментов не являются эксклюзивными. Только потому, что у вас есть runit, это не мешает вам использовать execline если хотите. Или вы можете запустить nosh скрипт под менеджером сервиса s6.

протоколирование

Вы пытались писать файлы журналов навсегда. Опять же, не используйте вечно. Это неправильный способ входа в систему с runit. Перенаправление стандартного вывода и ошибок непосредственно в файлы делает невозможным вращение журналов, ограничение размера и другие элементы управления без существенного вмешательства в работу вашего демона.

Все менеджеры сервисов семейства daemontools ведут журналирование, подключив выход одной основной службы через обычный канал к входу другой службы журналов. Этот канал настраивается сервис-менеджером. Вы не делаете это сами.

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

Эти программы multilog, multilog, s6-log, tinylog, cyclog, а также svlogd какой из них вы найдете в комплекте с runit.

На самом деле, вы можете найти того, кто бы ни создал /etc/service/MyApp уже настроил службу журналов в /etc/service/MyApp/log, Если нет, сценарий службы журнала очень прост:

 #! / bin / sh -e
exec chpst -uMyApp-log svlogd -t./main

Просто создайте учетную запись пользователя с именем MyApp-log, mkdir /etc/service/MyApp/log/main, chown MyApp-log /etc/service/MyApp/log/main и тебя нет (Обратите внимание, что main может быть символической ссылкой куда-то еще, где вы делаете каталог вместо. Вам не нужно помещать журналы под /etc с рунитом. Я помещаю свои каталоги журнала под /var/log/sv.)

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

дальнейшее чтение

Источник
Другие вопросы по тегам