Comments 54
Спасибо! Похоже полезная вещица, нужно попробовать для своих самоделок.
/о пользе пробелов/
Прочит название как r-unit, думал: юнит-тестирование добралось до демонов…
Прочит название как r-unit, думал: юнит-тестирование добралось до демонов…
А ссылка на готовый набор рецептов только у меня уходит в Not found?
У меня тоже, это всё НЛО виновато. Plain text: smarden.org/runit/runscripts.html
С upstart мирно соседствует? У нас в перемешку debian и ubuntu server, поэтому сейчас опакечиваю в стандартные init скрипты. А так можно было бы про runit задуматься.
Не ради холиварчика, а ради объективности :) Проверил в репозитариях ContOS, нет runit. Что подразумевается под большинством?
Однозначно. Более того, runit кое-что перенял у daemontools.
Рекомендую к прочтению habrahabr.ru/blogs/sysadm/83775/#comment_2497207
Акжан, а как насчет например reload'a типа nginx/apache — сначала тестим конфиг, потом, если всё ок — релоад? можно/нужно отдельные скрипты типа reload/restart/whatever класть?
У nginx есть уникальная фича обновления/рестарта сервиса без обрыва текущих соединений — к сожалению, с runit она не совместима.
Что касается простых вещей типа проверки синтаксиса конфига перед рестартом сервиса — это должно делаться без проблем т.к. runit позволяет установить юзерские скрипты-хуки на отправку сервису конкретных команд/сигналов. Так что вы можете написать скрипт в пару строк, который перехватит отправку сервису команды t(erm), проверит синтаксис конфига и либо пропустит команду t(erm), либо нет. Впрочем, лично я думаю, что это лишнее: если админ допускает синтаксические ошибки при редактировании конфига веб-сервера, то лучше всего этого админа не допускать до продакшн серверов, чем писать такие хуки.
Что касается простых вещей типа проверки синтаксиса конфига перед рестартом сервиса — это должно делаться без проблем т.к. runit позволяет установить юзерские скрипты-хуки на отправку сервису конкретных команд/сигналов. Так что вы можете написать скрипт в пару строк, который перехватит отправку сервису команды t(erm), проверит синтаксис конфига и либо пропустит команду t(erm), либо нет. Впрочем, лично я думаю, что это лишнее: если админ допускает синтаксические ошибки при редактировании конфига веб-сервера, то лучше всего этого админа не допускать до продакшн серверов, чем писать такие хуки.
Спасибо, пойду соберу rpm-ку для CentOS :)
Было бы неплохо упомянуть, что пакет runit это развитие (форк) DJBшного пакета daemontools. Софт DJB отличается надёжностью и простотой, но DJB очень не любит добавлять ненужные лично ему фичи — дабы не усложнять и не плодить баги. Пакет runit разрабатывается с учётом принципов DJB, автор тоже крайне неохотно добавляет новые фичи и стремится сохранить простоту кода, но всё-таки фич там больше и пользоваться runit удобнее, чем daemontools.
Стабильность runit, в принципе, не хуже, чем у daemontools — фактически я знаю только про один баг, который проявляется буквально у нескольких пользователей (включая меня, к сожалению), и который много лет не могут поймать (автору runit этот баг повторить не удаётся). Впрочем, для этого бага есть workaround, так что в результате всё работает много лет без нареканий.
Было бы неплохо упомянуть, что runit состоит из нескольких независимых частей: процесс N1 (т.е. замена стандартному /sbin/init), супервизор сервисов (который описан в статей) и утилита для управления логами. И можно пользоваться как всеми тремя составляющими, так и отдельно любой из них.
Мы много лет используем runit и для загрузки систем (вместо стандартного /sbin/init) и для запуска всех сервисов (вместо скриптов в /etc/init.d/). Для Gentoo пакет с runit, с примерами скриптов для загрузки системы и пакеты со скриптами для типовых сервисов доступны в моём оверлее для portage.
Так же мы используем супервизор сервисов из runit для запуска и управления всеми сервисами необходимыми для наших веб-проектов, при этом и супервизор и сервисы запускаются под обычным юзерским аккаунтом.
В статье не упомянуто одно из основных достоинств runit — он не использует .pid-файлы для контроля сервисов, т.к. это не атомарно и не надёжно. Вместо этого каждый сервис контролируется отдельным процессом-родителем, который в случае креша сервиса гарантированно и моментально получит SIGCHLD и перезапустит сервис.
Что касается каталогов /etc/sv/ и /etc/service/ — насколько я помню официальную позицию автора runit, рекомендуется использовать немного другие каталоги. Но вообще пути к каталогам нигде не прошиты, указываются параметром и можно выбирать их по своему вкусу — например, у меня это /service/ и /var/service/.
Что касается «демонизирования», то в статье это описано некорректно. Во-первых runit ничего не демонизирует (процесс демонизации несколько шире чем просто запуск процесса в фоне). Во-вторых runit не требует того, чтобы сервисы не демонизировали себя, в частности не отцеплялись от STDIN/OUT/ERR — он требует только того, чтобы сервисы не форкались в фоновый процесс. Логи сервисы не обязаны выводить на STDOUT/ERR, хотя это предпочтительный вариант. Впрочем, даже если сервисы выводят логи в файлы самостоятельно (как apache и mysql, к примеру), то это не мешает на месте файлов access_log, etc. разместить FIFO-шки, из которых будут читать svlogd-сервисы и выводить логи в традиционном для runit формате (у нас всё работает именно так).
Стабильность runit, в принципе, не хуже, чем у daemontools — фактически я знаю только про один баг, который проявляется буквально у нескольких пользователей (включая меня, к сожалению), и который много лет не могут поймать (автору runit этот баг повторить не удаётся). Впрочем, для этого бага есть workaround, так что в результате всё работает много лет без нареканий.
Было бы неплохо упомянуть, что runit состоит из нескольких независимых частей: процесс N1 (т.е. замена стандартному /sbin/init), супервизор сервисов (который описан в статей) и утилита для управления логами. И можно пользоваться как всеми тремя составляющими, так и отдельно любой из них.
Мы много лет используем runit и для загрузки систем (вместо стандартного /sbin/init) и для запуска всех сервисов (вместо скриптов в /etc/init.d/). Для Gentoo пакет с runit, с примерами скриптов для загрузки системы и пакеты со скриптами для типовых сервисов доступны в моём оверлее для portage.
Так же мы используем супервизор сервисов из runit для запуска и управления всеми сервисами необходимыми для наших веб-проектов, при этом и супервизор и сервисы запускаются под обычным юзерским аккаунтом.
В статье не упомянуто одно из основных достоинств runit — он не использует .pid-файлы для контроля сервисов, т.к. это не атомарно и не надёжно. Вместо этого каждый сервис контролируется отдельным процессом-родителем, который в случае креша сервиса гарантированно и моментально получит SIGCHLD и перезапустит сервис.
Что касается каталогов /etc/sv/ и /etc/service/ — насколько я помню официальную позицию автора runit, рекомендуется использовать немного другие каталоги. Но вообще пути к каталогам нигде не прошиты, указываются параметром и можно выбирать их по своему вкусу — например, у меня это /service/ и /var/service/.
Что касается «демонизирования», то в статье это описано некорректно. Во-первых runit ничего не демонизирует (процесс демонизации несколько шире чем просто запуск процесса в фоне). Во-вторых runit не требует того, чтобы сервисы не демонизировали себя, в частности не отцеплялись от STDIN/OUT/ERR — он требует только того, чтобы сервисы не форкались в фоновый процесс. Логи сервисы не обязаны выводить на STDOUT/ERR, хотя это предпочтительный вариант. Впрочем, даже если сервисы выводят логи в файлы самостоятельно (как apache и mysql, к примеру), то это не мешает на месте файлов access_log, etc. разместить FIFO-шки, из которых будут читать svlogd-сервисы и выводить логи в традиционном для runit формате (у нас всё работает именно так).
Хорошая статья. Спасибо.
Что там с демонизацией? Что то типа tcpserv есть? Если да то как работает — форк на каждый запрос?
Демонизации (в чистом виде) нет.
Подробнее в комменте от poweman выше.
Подробнее в комменте от poweman выше.
Если я правильно догадался, что такое tcpserv, то такая утилита есть в DJBшном пакете ucspi-tcp, называется tcpserver.
runit c вебинтерфесом это supervisord.org/ для серверных ферм гораздо удобнее за счет управления через xml-rpc
Никто не мешает использовать REST-сигналы с runit-man.
решения наподобие supervisord обладают своими преимуществами и недостатками.
очень долго их расписывать. В общем случае нужна как система мониторинга локально на машине (runit), так и удалённая (например, cacti/nagios).
решения наподобие supervisord обладают своими преимуществами и недостатками.
очень долго их расписывать. В общем случае нужна как система мониторинга локально на машине (runit), так и удалённая (например, cacti/nagios).
где написано что что то мешает?
зачем использовать runit + нашлепку сбоку на ruby если можно поставить supervisord который все умеет сам без постороенней помощи. По возможностям они абсолютно идентичны. runit хорошь там где мало ресурсов в embedded или на vps, но он не предназначен для распределенного управления.
runit это не мониторинг, это супервайзер для процессов.
зачем использовать runit + нашлепку сбоку на ruby если можно поставить supervisord который все умеет сам без постороенней помощи. По возможностям они абсолютно идентичны. runit хорошь там где мало ресурсов в embedded или на vps, но он не предназначен для распределенного управления.
runit это не мониторинг, это супервайзер для процессов.
Коллеги!
А что я делаю не так:
Запускаем:
Проверяем:
Где я ошибся?
А что я делаю не так:
$ cat /etc/sv/spawn-fcgi/run
#!/bin/sh
exec 2>&1
PHP_FCGI_CHILDREN=5 \
PHP_FCGI_MAX_REQUESTS=1000 \
exec /usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -g www-data -n -- /usr/bin/php5-cgi
Запускаем:
# sv up spawn-fcgi
Проверяем:
# sv status spawn-fcgi
run: spawn-fcgi: (pid 435) 1s
# sv status spawn-fcgi
run: spawn-fcgi: (pid 446) 1s
# sv status spawn-fcgi
run: spawn-fcgi: (pid 450) 1s
# sv status spawn-fcgi
run: spawn-fcgi: (pid 454) 1s
Где я ошибся?
А что делать с сервисами, не умеющими не отвязываться от консоли?
zabbix-server например.
zabbix-server например.
Вообще-то для запуска сервисов runit отвязка от консоли не нужна и даже вредна.
Я наоборот, убираю всякие опции демонизации. Мне удобнее, чтобы ошибки сыпались в stdout/stderr, их оттуда подхватит svlogd.
Я наоборот, убираю всякие опции демонизации. Мне удобнее, чтобы ошибки сыпались в stdout/stderr, их оттуда подхватит svlogd.
Так о том и речь — он НЕ умеет НЕ отвязываться.
Он сразу после запуска форкается и уходит в бэкграунд.
Runit его тут же теряет есессна.
Он сразу после запуска форкается и уходит в бэкграунд.
Runit его тут же теряет есессна.
подстава :) в таком случае сам процесс в runit не подсунуть, к сожалению.
либо оставить как есть, либо писать оберточный процесс (daemon controller), либо писать feature request авторам zabbix.
всё-таки у них должна быть фича запускать сервер в фореграунде, хотя бы для отладки.
либо оставить как есть, либо писать оберточный процесс (daemon controller), либо писать feature request авторам zabbix.
всё-таки у них должна быть фича запускать сервер в фореграунде, хотя бы для отладки.
orion www # /etc/init.d/unicorn start
fail: unicorn: runsv not running
Если же перед этим сделать
runsv /var/service/unicornТо всё ок, только это же не выход
у вас, видимо, не запущен супервизор runsvdir.
Возможно я что-то неверно делаю, но запуск runsvdir запускает мне всех моих демонов
Sign up to leave a comment.
Использование runit для своих сервисов