Не используйте навсегда.

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

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

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

Существуют различные языки сценариев, которые делают запись такого run программирует пустяк. Laurent Bercot execline тот. Мой nosh программа - другой. Предположение этого bin/www фактическая исполняемая программа для Вашего dæmon, еды run сценарий посмотрел бы что-то как:

#!/bin/nosh
fdmove -c 2 1
chdir /src
bin/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 программы.

запуск и остановка dæmons

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

• runit имеет sv программа: sv down /etc/service/MyApp
• s6 имеет s6-svc программа: s6-svc -d /etc/service/MyApp
• perp имеет 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 если Вы хотите. Или можно выполнить a nosh сценарий при менеджере по сервису s6.

вход

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

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

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

Эти программы 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 с runit. Я поместил свои каталоги журнала под /var/log/sv.)

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

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

• Jonathan de Boyne Pollard (2001). "Не разветвляйтесь () для 'помещения dæmon в фон'".. Ошибки избежать при разработке Unix dæmon программы. Часто, Учитывая Ответы.
• Jonathan de Boyne Pollard (2014). Бок о бок смотрят на запущенные скрипты и сервисные единицы.. Часто, Учитывая Ответы.
• https://stackoverflow.com/a/21554947/340790
• https://superuser.com/a/868519/38062
• Gerrit Pape. Набор запущенных скриптов.