Что: 3aab9abdcda9d1822fe92143a9c8291cadaf1852
Когда: 2020-08-26 15:59:16+03:00
Темы: djb systemd time tip
Продолжаю познавать мир DJB софта: daemontools
http://cr.yp.to/daemontools.html
https://en.wikipedia.org/wiki/Daemontools
https://wiki.gentoo.org/wiki/Daemontools-encore
http://smarden.org/runit/
Про daemontools я слышал давно. Как и про redo. И при установке curvedns
мне очень не нравилось что она тащит за собой эту систему, под которой
будет всего лишь ровно один процесс. Но решил копнуть поглубже и
разобраться чем хороша/плоха, стоит ли.
Мне в общем-то всегда вроде хватало и FreeBSD rc.d запускалки. Но,
некоторые службы при определённых условиях не запускаются (например не
примонтирован раздел требующий ручного предоставления ключа). Я их
запускал руками повторно. Но вот как-то надоело это. Плюс про
daemontools помню (особенно поле redo, на который я тоже долгое время не
обращал внимания).
Как и всё DJB-ное, daemontools имеют минимальный порог входа. Решил я
пару демонов перевести под его управление. mkdir, run файл на 1-3
строки, chmod +x и готово. Как минимум уже профит от того, что каждые
пять секунд они будут пытаться быть запущенными, а также перезапустятся
когда упадут.
В основном люди пишут про нелюбовь к "простым" системам запуска типа
SysV/whatever потому что там надо писать shell-скрипты. И там они
действительно на себя очень много чего берут. FreeBSD rc.d это, чисто
технически, тоже shell-скрипт, но в котором по умолчанию декларативные
вещи задаются, не отличаясь своей сутью от какого-нибудь upstart и
поэтому там все эти говны про shell не применимы.
Но вот из коробки rc.d не предоставляет supervising -- если кто-то
упал... ну что, значит упал, не наша проблема. daemontools это уже
supervising с возможностью отсылки сигналов, останова, перезапуска и
прочего.
inittab ttys init.d rc.local /service
Easy service installation and removal No No Yes No Yes
Easy first-time service startup No No No No Yes
Reliable restarts Yes Yes No No Yes
Easy, reliable signalling No No No No Yes
Clean process state Yes Yes No No Yes
Portability No No No No Yes
У меня пара демонов на сервере осталась под наблюдением monit, но,
думаю, что перенесу под daemontools, ибо пока с ними вообще всё без
проблем.
Подход с envdir командой очень понравился: envdir dir cmd -- прочитает
файлы из dir, где каждое имя файла будет названием переменной окружения,
а его содержимое будет её значением, и запустит с этим env-ом cmd.
Приватный ключ в curvedns передаётся именно таким способом. Мне это
понравилось тем, что конфигурировать демона можно просто выполняя echo в
эти файлы. Например если под rc.d мне надо запустить два демона с одним
именем/скриптом, то не выйдет -- надо например копировать rc-скрипт и
менять в нём имя демона. Выглядит не сложно, но отнимает время и
выглядит костылём. С daemontools создание копии директории выглядит
абсолютно естественно.
С логами особо не игрался, но подход тоже пока очень понравился: прям по
примеру легко добавил ротируемый лог с timestamp-ами. Использовал
"родной" для daemontools multilog. А ведь можно и в syslog или ещё как
засунуть что угодно. Взятие управления логами сторонней программой, а не
самой прикладной -- это правильно. Ротация логов через посылку HUP
программе, чтобы она "отпустила" файловый дескриптор -- распространённая
практика, но блин, костыль же! Полно софта который не выставляет
timestamp-ы. А подход daemontools с TAI64 тоже продуман -- не нужно
думать о формате и при чтении его можно на любой систем сконвертировать
в нужный (утилита есть, делает всё как надо).
Возня с PID-файлами тоже костыль: если будет race (а он обязательно
будет по закону Мёрфи), то теряется информация о запущенном процессе.
Нужен надсмотрщик и никак иначе!
Указание директорий для всяких svok/svstat программ -- непривычно, но
правильно и корректно! И "." и "*" сработает. setuidgid прост и
работает. readproctitle выглядит интересно, хотя на деле ещё не
пробовал. Делать зависимости между демонами вообще не проблема, раз и
так это всё делается в shell скриптах.
Но это требует чтобы демоны не демонизировались. А кто не умеет, то есть
fghack программа. Но сам я на деле не пробовал этого ничего. Мои Go
программы не демонизируются и правильно делают, с точки зрения DJB! А
вот логи пишут в stderr, что не проблема, так как достаточно сделать
exec 2>&1 для перенаправления в stdout.
В общем я тоже под впечатлением от дикой простоты и уже получаемого
профита. Система s6 -- полностью сделана на этих идеях и содержит просто
немного побольше tools. А более продвинутый runit уже может быть PID=1
процессом. Я слышал про runit, когда активно шли войны systemd vs
everything else, но никогда не читал про него. Теперь вижу что он из
себя представляет и однозначно считаю что это лучшее что видел (для
замены PID=1). Я имел дело с upstart -- он работает, но это же
классический "а мы сделаем свой декларативный язык с кучей плюшек и
фишек": нет хакерской простоты и элегантности.
Сгенерирован: SGBlog 0.34.0