Вроде бы как мы берем операционную систему для того, чтобы экономить время на таких вещах. Вроде как пакеты должны были облегчить нам жизнь. Весьма возможно, что мой выбор операционной системы был плох, но до сегодняшнего дня жить в области Debian/Ubuntu мне было вполне комфортно.
С другой стороны, «было» — это условность. Все мы часто находимся в относительном неведении относительно того, как устроена наша операционная система. А однажды увидев код /usr/sbin/service ты уже не можешь развидеть его. Так же как и пользоваться этим инструментом.
Наверное, нужно вернуться обратно. Чтобы понять, как мы оказались в такой заднице со смесью SysV и systemd, приправленной Upstart.
TL; DR: автор ноет по поводу зоопарка из SysV, Upstart и systemd в современных дистрибутивах Debian/Ubuntu.
SysV
Казалось бы, что может быть проще? В директории /etc/init.d/ находится файл с именем службы, он отвечает за запуск и остановку. Мы делаем /etc/init.d/service stop или /etc/init.d/service start и все работает отлично.
Операционная система делает то же самое, только в зависимости от runlevel, два — так два, буду последовательно выполнять симлинки из /etc/rc2.d, которые по сути своей ведут к /etc/init.d, жизнь проста и прекрасна. Чтобы управлять последовательностью достаточно изменить сортировку файлов при помощи числа. Есть утилиты, чтобы автоматизировать создание этих симлинков.
Почему мы не могли остаться в том месте? Потому что системы изменились. Они стали, гм, сложными.
Во-первых, состояние системы ранее было практически монолитным, а сегодня может быть изменчивым. Бах — и по USB подключили сетевой адаптер. При Томпсоне такого не было! Надо реагировать, т.е. уведомить службы об этом, кого-то перезапустить, кого-то запустить, кого-то погасить.
Во-вторых, SysV было глубоко плевать на интимную жизнь программ. Он их запускал на старте, но если у тебя что-то не получалось, то это были твои личные проблемы. Отлаживать такие вещи, кстати, практически невозможно. Segmentation fault? Настоящие мужчины пишут программы, которые запускаются с первого раза и не сегфолтят, слабак.
В-третьих, структура зависимостей в SysV была достаточно простая, чего не всегда хватало.
В-четвертых, старт системы не мог быть параллельным. Запуск скриптов был строго последовательный. Это легко увидеть, если посмотреть на время старта OpenSUSE, например, лохматой 12 версии.
Правда, основная особенность SysV была не только в простоте. С простотой приходили проблемы. Например, если у меня каждый запуск скрипта start или stop отдельный, то как узнать, запущена программа или нет? Ведь ей нужно послать сигнал kill, а без PID его посылать некуда.
Свежей идеей было хранить эту цифру в файле .pid, прямо ну серьезно, свежей для своих далеких лет. Однако что делать, если программа вылетела с segmentation fault? Кратко: ничего, PID надо проверить, перед тем, как использовать.
Upstart
Мне кажется, что проблемы начались как раз тут. То есть, с того, как сообщество приняло Upstart. Это и задало дальнейший тон. Но по порядку.
Upstart поддерживал события. Он мог следить и перезапускать программы. Он умел выстраивать зависимости. Ну и с параллельностью у него тоже было все в порядке.
Кроме одной, огромной бочки дегтя, о которой я скажу дальше, я не помню никаких толком претензий к Upstart. А вот бочкой было то, что разработчики софта его в целом проигнорировали.
Почему? Я не знаю. Скорее всего потому, что совместимость с SysV была приоритетом для Upstart. Поэтому разработчикам ничего не нужно было менять.
В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта так и не перешло на него!
С одной стороны, я не могу винить в этом только разработчиков. Они, в конце концов, пишут программы. Как лучше запускать эти программы в системе — не их дело. Однако скрипты для SysV они пишут. Хотите примеров? Посмотрите, на что похож скрипт запуска postfix в Debian. Этот код монструозен, он ужасен, это же просто страшно.
Однако еще страшнее то, что многие администраторы вообще не видят и не понимают разницы. Они пишут:
sudo service apache2 startИ свято верят, что apache2 должен стартовать. Аргх, он не должен. Понимаете? Не должен. Запустится утилита /usr/bin/service, которая примется со страшной силой угадывать, как же нужно стартовать эту службу, а потом передаст вашу просьбу SysV или Upstart. Если сможет правильно угадать, ага.
service вообще не часть пакета Upstart. Оно вообще не оттуда, но как-то уживается в этом веселом кругу. Чтобы увеличить количество ада, некоторые разработчики делают скрипты /etc/init.d ссылающимися на Upstart. Эдакий уроборос, чтобы если вдруг администратор из лесу вышел и в Ubuntu 16.04 LTS напишет
/etc/init.d/service restartЧтобы все работало.
Отдельно следует сказать про PID. Upstart не нужен PID в файле. Почему? Потому что любой запущенный им процесс остается его дочерним. Если вдруг он вылетит, то Upstart об этом узнает. И поскольку команды запуска и остановки тоже проходят через него, то тут нет никакой проблемы.
Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.
Да что уж там, сейчас, когда 16.04 LTS уже здесь, как думаете, при помощи чего стартует Apache2? postfix? Еще куча всякого? SysV.
Правда, в 16.04 им помогает systemd.
systemd
В целом, мне нравится systemd, честно. Его логика мне гораздо приятнее той, что была у Upstart. Правда, если бы еще Debian взяла бы не 215 релиз, а 218, то жить было бы еще лучше, но черт с ним, мы переживем и без команды edit, если надо.
И systemd можно долго ругать, но это уже стандарт. Однако как вы думаете, что делают разработчики с systemd? В основном игнорируют.
Итак, что привнес systemd? Генераторы! Тысячи их!
Кратко, если Upstart не выпендривался, а просто повторял поведение SysV, то systemd до такого не опускается. Он берет существующий /etc/init.d/service и на основе него генерирует скрипт для systemd. Его потом и запускает.
ExecStart=/etc/init.d/service start
ExecStop=/etc/init.d/service stopНу вот как бы да, вот примерно вот так оно и получается. Я не буду рассказывать о том, что это далеко не всегда работает так, как надо. Вернее, стартовать оно стартует. Не вздумайте в каком-нибудь продакшене положиться на рестарт такого сервиса, мониторинг станет вашим лучшим будильником.
И да, вы же понимаете, что systemd тем более не нужен PID, но увы. В сообществе это до сих пор остается толком не понятым.
К разработчикам
Да, ребята, я согласен, еще раз, запуск программы не есть ваша забота. Однако кто, как не вы, лучше знает, как спроектировать беспроблемный старт? Ведь одно дело, если команда старта выглядит так:
ExecStart=/usr/bin/control-bin startА совсем другое, если так:
ExecStart=/usr/sbin/postfwd2 --file=/etc/postfwd/postfwd.cf --interface=127.0.0.1 --port=10040 --shortlog --summary=600 --cache=600 --cache-rbl-timeout=3600 --cleanup-requests=1200 --cleanup-rbls=1800 --cleanup-rates=1200 --user=postfwd --group=postfwdДавайте перестанем уже размазывать настройки между /etc/config.conf и /etc/default/service?
Давайте перестанем пытаться управлять стартом службы при помощи параметра START=yes в /etc/default/service? Нет, я понимаю, что «xyes» смотрится отличной шуткой, но надоело уже!
Давайте уже решим, что systemd — он везде. И что под него можно смело адаптироваться.
К самому себе
Смирись, тряпка, и не ной. Keep calm and systemd.
Комментарии (169)
Loki3000
17.08.2016 17:24+5В защиту SysV хочу сказать, что он предельно прост и понятен широчайшим слоям пользователей. Даже полные ламеры, вроде меня, способны в кратчайшие сроки, при помощи гугла, форумов и старших товарищей слепить удобоваримый скрипт запуска демона. Более того, достаточно прозрачен механизм работы: просто посмотрев содержимое каталога, можно понять что и когда будет запущено. И контрольный в голову: этот скрипт из желудей и веток будет беспроблемно работать годами. А если перестанет, то его в состоянии будет починить практически любой, кто немного знаком с линуксом.
В противовес же SysV, чтобы что-то настроить в systemd, нужно освоить мануал на 10 страниц, все эти юниты со своими конфигами и синтаксисом, этот systemctl с непонятными параметрами… я не админ, мне не нужна эта информация на каждый день (кстати, сдается мне что админам она тоже нужна далеко не каждый день), мне раз в пять лет надо настроить запуск демона и забыть про него. Средствами файловой системы это сделать много проще и понятнее.
Вот лично для меня systemd не несет никаких удобств. Быть может поэтому его и многие другие игнорируют?
prometheus_ru
17.08.2016 17:27+4Прочитайте внимательно. Бывает, что скрипты на SysV стартуют, однако приложение по какой-то причине вываливается на старте. Что делать? Я понимаю, запустить руками. Но без режима контроля и рестарта многие современные приложения тупо не работают нормально.
Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом.
А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.Loki3000
17.08.2016 17:46Да я прочитал. Да, бывает. Правда, в моей практике приложения падали и при запуске скриптом и при запуске руками, так что все это достаточно просто диагностировалось. Видимо просто сложных случаев не было.
Удобоваримый — это тот который, несмотря на всю свою кривизну, выполняет возложенные на него функции.
Не админу достаточно одну статью прочитать с базисом.
Эх, вашими бы устами… я вот сейчас почитал вводную статью, посмотрел примеры в своей системе. Понял что я по прежнему не имею представления в каком порядке все это запускается… понял что если вот прямо сейчас я немного уловил логику конструирования всего этого, то год спустя мне всю процедуру (включая чтение вводной статьи) придется начинать сначала.
Вы в статье спрашивали почему все так держатся за SysV? Я ответил почему за него держусь я.khim
17.08.2016 19:11+2Понял что я по прежнему не имею представления в каком порядке все это запускается…
А почему вы считаете что есть какой-то один порядок и почему вас это вообще волнует?
Вы когда Makefile пишите тоже пытаетесь вычислить в какой последовательности файлы будут компилироваться?Loki3000
18.08.2016 00:02-1какой-то один порядок и почему вас это вообще волнует?
Почти в 100% случаев не волнует. Но я могу себе представить случай, когда надо запустить какой-нибудь условный торрент-клиент, который будет работать с файлами на смонтированных шарах. Мне кажется логичным, чтобы сначала запускался скрипт монтирования, а уже потом — приложение, которое с шарами будет работать. Параллельно их можно выполнить, но кто поручится за результат?
grossws
18.08.2016 00:21+4И для этого в
systemdесть зависимости между unit'ами, чего фактически нет вrunit, который всякие странные люди приводят как альтернативуsystemd.
Указываете, для вашего условного
rtorrent.serviceRequires=media-share.mount+After=media-share.mountи всё работает. При попытке запуститьrtorrent.serviceбудет монитроваться шара и основной юнит будет запускаться после, при попытке отмонтирования шары будет останавливаться сервис.Loki3000
18.08.2016 09:10-5Я прям не знаю, вы все как будто придуриваетесь:) Перечитайте мой первый комментарий: я не админ и не хочу им быть. Я простой пользователь. И у меня, пользователя, пытаются отнять простой инструмент и дают взамен сложный. И эта замена мне, пользователю, никаких плюшек не сулит. Это как у среднестатистического водителя отнять 5-ступенчатую коробку передач и дать ему взамен 25-ступенчатую. Оно может и здорово и на всякой спецтехнике я встречал нечто подобное, но обычному водителю-то это нафига?
grossws
18.08.2016 17:33Если вы выступаете в роли простого пользователя, а не админа (пусть и локалхоста), то вы не будете писать инит-скрипты/юниты, а будете использовать готовое приложение (вероятно, с gui или tui). В случае, если вас что-то не устраивает, то (в этой роли) будете писать feature request'ы и излагать своё видение проблемы на форуме/в багтрекере etc.
Иначе вы принимаете роль админа, которая требует понимания своих действий и банального умения читать документацию. И ваша жалоба не несёт никакого смысла.
VBKesha
17.08.2016 17:46Предположим приложение упало, что сделает systemd?
Проанализирует ошибку с которой упало приложение и исправит или тупо перезапустит снова?prometheus_ru
17.08.2016 17:54Для начала, узнает, почему упало. Т.е. если его остановил админ, то перезапускать не надо.
Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось.
Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли его перезапускать. С systemd он будет перезапущен без Вас.VBKesha
17.08.2016 18:01Предположим что это не postfix и что то случилось с данными на диске и сервис из за этого падает. А при старте он жрёт много процессорного времени и снова падает. В итоге из за systemd лежать весь сервер, да так гораздо лучше.
А для падучих сервисов ну можно расписать скрипт который висит в памяти и сам перезапускает упавший сервис. Что в своё время я и делал для одного игрового сервиса.
Я ничего против systemd не имею, но я им и не пользуюсь, однако усложнение системы старта когда не можешь найти, где, что и как стартует не радует.prometheus_ru
17.08.2016 18:03Нет, вы можете указать, сколько раз пытаться перезапускать. Дефолтных значений типа 5 хватает.
А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.VBKesha
17.08.2016 18:09>> А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вот именно если вылетит мой скрипт то в целом жить можно а если systemd то да жизнь сложней.
>> Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны. И за много лет как я с этим познакомился ничего не поменялось. Всё как то по старому.
Я не знаю что должен был решить systemd, может по этому и не понимаю зачем он.prometheus_ru
17.08.2016 18:11+1Я же еще раз говорю, получается яицо в яице: мы пишем скрипт, который следит за скриптом, который следит за скриптом.
У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с ошибкой. И никак не перезапускалось. И жизнь — боль :)4144
18.08.2016 00:50У других людей было что именно сам монстробразный systemd падал. Т.к. он слишком много делает в init процессе.
И как может простой скрипт на баше упасть, и чтобы не упал init и другие процессы?
crlam0
17.08.2016 22:36+1Очень жаль, что OpenRC практически нигде кроме Gentoo и производных не пытались использовать :( А ведь в ней реализована и работа с зависимостями, и параллельный запуск (на сколько помню, в тестовом режиме, но тем не менее), а главное весьма простые и логичные скрипты запуска. Даже контейнеры можно с ней запускать. Да, по сравнению с SystemD нет работы с cgroups, нет отслеживания запущенных процессов, но зато это и не такой комбайн, включающий в себя очень много того, что имхо к системе инициализации отношения или не имеет, или имеет, но очень отдаленное.
kachsheev
18.08.2016 00:25В принципе, ничего не мешает использовать её в deb-based дистрибутиве. Не знаю как сейчас, но раньше она там вполе сносно справлялась с управлением демонами.
crlam0
18.08.2016 00:40Я в курсе, так же как и в Gentoo ничего не мешает использовать SystemD. И даже более того: если мне не изменяет память, в голосовании за новую систему инициализации в Debian мелькала OpenRC. Но факт остается фактом: в целом неплохое решение осталось нишевым, это и печалит.
quarckster
17.08.2016 22:36Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны.
Админу локалхоста наверное больше и не нужно.
zunkree
18.08.2016 00:59+2Как раз навороченные фичи systemd более востребованы на локалхостах, это именно там часто меняется конфигурация оборудования, сетей и сервисов. В серверах все много более стабильно и большинство фичей избыточно.
UnixMaster
17.08.2016 18:08+1А разве при написание «юнита» systemd админ не может указать, чтобы systemd его не перезапускал? Специально не искал, но как будто бы можно. Я только пару раз автоматизировал старт Java приложений под systemd и проблем там не увидел, в отличие от SysV. там есть практически все, просто нужно правильно это испоьзовать.
VBKesha
17.08.2016 18:12+4Админ ленив, чтобы читать мануалы как расписать ещё один скрипт для ещё одной системы старта, которая моложе чем аптайм его сервера.
khim
17.08.2016 19:14+3Если админ хочет работать только с серврами, который были запущены до появления systemd, то почему его вообще волнует что происходит в современных дистрибутивах Linux?
UnixMaster
17.08.2016 19:30Видимо программисты сами должны писать скрипты запуска для самописных приложений(что большинство и делает), а админы ленивые и консервативные. И не в их интересах отрываться от «важных» задач, чтобы идти в ногу со временем.
VBKesha
17.08.2016 22:43Linux используют не только админы. Он сейчас и в embeded распространён. И вот когда попадается железка на которой стоит systemd(свежие чуть ли не поголовно) и задача стоит вырезать всё лишнее, и сделать старт максимально быстрым. То тут приходится узнавать что это за хрень и как её есть. Ну или второй вариант init из busybox и пару простых скриптов. Чтобы не думать какого хрена всё таки запустился wpa-suplicant хотя ты точно его прибивал.
dartraiden
17.08.2016 20:11+7Если админ не хочется развиваться, идти в ногу со временем, и поглядывать на новые веяния — это его выбор. Но ничего удивительного, что это путь к профессиональному застою со всеми вытекающими последствиями.
В некоторые профессиях (например, бухгалтерское дело) без постоянного отслеживания изменений и нововведений вообще работать невозможно. Попробуйте в 2016 году вести бухучет по нормативам 2000 года…
foxmuldercp
25.08.2016 18:41-2И как мне простите, работать с этим бинарным логом, особенно если бинарное ,… забило мне /var/log под завязку и побилось? как мне присобачить к нему какойнить… да хотя бы fail2ban на ssh перебор? глаза бы мои этого journalg не видели, если честно.
А вот паралельный стар хорош и быстр. Но у меня, например поверднс должен стартовать после постгреса, а докер после поверднса. а потом нгинкс, на закуску. А в результате я хожу ручками и перестартовываю всю эту цепочку потому как при очередном апт-гет апдейт у нас половина моих кастомных конфигов юнитов обновилась на те что шли с пакетом
evg_krsk
25.08.2016 21:50+4Да, есть такая проблема, текущий формат журнала довольно хрупок. Но он хотя бы умеет сам свой размер на диске ограничивать, в отличии от.
Значит, вы что-то делаете не так. Админ свои самописные юниты должен класть в /etc/systemd/system чтобы они не затирались вендорскими. Но в большинстве случаев и этого не нужно, достаточно systemctl edit foo.service и дописать/перекрыть/дополнить только нужные куски. В т.к. и объяснить, что после чего должно стартовать на конретной машине, можно так. Почитайте документацию по systemd, это окупится.
grossws
26.08.2016 04:12Но в большинстве случаев и этого не нужно, достаточно systemctl edit foo.service и дописать/перекрыть/дополнить только нужные куски.
Edit есть не во всех широкоиспользуемых версиях systemd. Но он де-факто создаёт такой же drop-in, который рекомендуется создавать пользователю (типа
/etc/systemd/system/nginx.service.d/override.conf).
foxmuldercp
26.08.2016 21:45Но он хотя бы умеет сам свой размер на диске ограничивать
Если файл лога быстро разростается — проблема НЕ в его разростании. а в том ПОЧЕМУ он стал разростаться, и это уже ТРИГГЕР даже в обычном заббиксе о проблеме. То, что он затрёт мне события часовой давности — это минус.
классический рсислог в этом случае проще, удобнее и приятнее — на одном из соседних проектов логи складываются в SQL, logstash и ещё в архив отдельный. а держать journald чтобы он отправлял данные в rsyslog, который разложит логи куда надо на этой же машине — я считаю оверхедом.
grossws
26.08.2016 04:09А в результате я хожу ручками и перестартовываю всю эту цепочку потому как при очередном апт-гет апдейт у нас половина моих кастомных конфигов юнитов обновилась на те что шли с пакетом
А вы их в
/usr/lib/systemd/systemмодифицируете или всё-таки в/etc/systemd/system, как положено? Т. е. вопрос в том мейнтейнеры debian/ubuntu не смогли набратьman 5 systemd.unitили вы.
Алсо, fail2ban прекрасно работает с journald. Нет принципиально никакой разницы прочитать целиком файл или stdout от
journalctl _SYSTEMD_UNIT=sshd.service + _COMM=sshd. Причём последнему можно ещё указать--since. Если захотите настроить, а не ныть на хабре — гуглите параметрjournalmatchв настройках фильтров. Ну или посмотрите как оно настроено, например, в centos 7.foxmuldercp
26.08.2016 21:47Спасибо за совет, изначально проблема была не в fail2ban, на самом деле, но возьму на заметку…
handicraftsman
18.08.2016 12:48Я так вообще извращался: писал скрипты старта-запуска jenkins'а (дефолтного с war-ом не поставляется), копипастил (ну не то, чтобы я разбираюсь в почти-rc-конфигах (по сути) sysD) файл сервиса (любого) в нужное мне место, а затем правил его, вписывая адреса нужных мне скриптов, а также правя название.
SchmeL
18.08.2016 17:50+3А мне наоборот systemd нравится своей простотой. Скрипты SysV очень монструозные, и раньше я всегда «таскал» их с гугла, пару раз приходилось писать свой сервис и это заняло тогда много времени, тогда как в systemd сервис пишется за несколько минут на коленке, достаточно скормить исполняему файлу параметры запуска и останова.
amarao
19.08.2016 16:10+2Нет. Юнит на systemd пишется в 4 строчки и не содержит в себе никакой магии. А вот ритуалы sysv-init (с подключением functions, использованием start-stop-daemon) — вот это реальная магия. Отладка же этой магии — то ещё развлечение.
Непривычно — да. Но это быстро проходит.
inkvizitor68sl
17.08.2016 17:40-3Всё, что я думаю о systemd в одной картинке — https://pbs.twimg.com/media/ChIcfpoXEAAPgFN.jpg
prometheus_ru
17.08.2016 17:43+2Вы привели отличный пример уробороса. Автор пытается рестартовать службу при помощи /etc/init.d/service, что по сути работать не должно.
Однако в системе кто-то об этом побеспокоился и сделал велосипед /etc/init.d/service -> systemd, но что-то пошло не так, поскольку надо смотреть, как написан .service-файл.inkvizitor68sl
17.08.2016 17:48-3> что по сути работать не должно.
Вообще отношения к делу не имеет.
root@libra:~# systemctl start rsync
root@libra:~# echo $?
0
root@libra:~# telnet localhost 873
Trying ::1…
Trying 127.0.0.1…
telnet: Unable to connect to remote host: Connection refused
Полагаться на systemd нельзя. У него даже при несоблюдении ConditionPathExists «всё хорошо, я всё запустил, наслаждайтесь».
Может идея-то в базе у systemd и хорошая, но написан он настолько коряво и настолько нелогично, что проще похоронить (что и случится лет через 5), чем тратить время на разбирательства.prometheus_ru
17.08.2016 17:55+4systemctl cat rsync в студию, покажите. Для начала разберемся, как оно запускается. Но /etc/init.d/service с systemd надо забыть.
inkvizitor68sl
17.08.2016 18:12root@libra:~# systemctl cat rsync # /lib/systemd/system/rsync.service [Unit] Description=fast remote file copy program daemon ConditionPathExists=/etc/rsyncd.conf [Service] ExecStart=/usr/bin/rsync --daemon --no-detach [Install] WantedBy=multi-user.targetprometheus_ru
17.08.2016 18:30+3Сразу по косякам.
--daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все хорошо. Type= не указано, поэтому systemd считает, что это simple.
1. Я бы попробовал добавить Type=forking в секцию Service.
2. У rsync очень особое понимание того, как оно запущено. --daemon обозначает не просто fork, а еще пояснение, что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так:
[Service]
Type=simple
ExecStart=/usr/bin/rsyncinkvizitor68sl
17.08.2016 18:36Type=simple Type=forking ExecStart=/usr/bin/rsync --no-detach --daemon Type=simple ExecStart=/usr/bin/rsync --no-detach --daemon Type=simple ExecStart=/usr/bin/rsync --no-detach Type=simple ExecStart=/usr/bin/rsync
Во всех случаях:
root@libra:~# systemctl start rsync; echo $?
0
Anyway, какую бы чушь я не писал в [service], повторюсь — ConditionPathExists=/etc/rsyncd.conf не работает. Файла нет, systemctl возвращает 0 (пытается запустить rsync), хотя даже не должен пытаться.prometheus_ru
17.08.2016 18:39+1Он, судя по всему, не пытается. Из документации следует, что если эта проверка фейлится, то systemd делает вид, что все хорошо и не переводит unit в режим failed.
Before starting a unit, verify that the specified condition is true. If it is not true, the starting of the unit will be (mostly silently) skipped, however all ordering dependencies of it are still respected. A failing condition will not result in the unit being moved into a failure state.
inkvizitor68sl
17.08.2016 18:42-1Я и говорю — к черту это нелогичное поделие не нужно. Поэтому никто и не торопится переезжать.
prometheus_ru
17.08.2016 18:44+3Так логично же, юнит в порядке, он без ошибок, просто не сконфигурирован сейчас. Поэтому и не запустился.
Я не понимаю, что здесь нелогичного?
bobelev
17.08.2016 18:39А что пишет
systemctl status rsync?inkvizitor68sl
17.08.2016 18:40-2? rsync.service — fast remote file copy program daemon
Loaded: loaded (/lib/systemd/system/rsync.service; disabled)
Active: inactive (dead)
prometheus_ru
17.08.2016 18:41Ваш коммент ниже подтверждает, что все именно так, как в документации :)
inkvizitor68sl
17.08.2016 18:42-3Вот только приложение не запустилось, а я об этом ничего не узнал. А что там в документации — мне в целом наплевать, как пользователю ;)
masai
17.08.2016 21:28Если хотите, чтобы не запускалось, то используйте
AssertPathExists=вместоConditionPathExists=. Или я неправильно понимаю суть проблемы?
UnixMaster
17.08.2016 19:37+1Да все работает -> вопрос на stackoverflow..
И тогда:
[Unit]
Description=fast remote file copy program daemon
ConditionPathExists=!/etc/rsyncd.conf1
[Service]
ExecStart=/usr/bin/rsync --daemon --no-detach
Environment=SYSTEMD_LOG_LEVEL=debug
Type=forking
[Install]
WantedBy=multi-user.target
Видим результат:
[root@laptop system]# systemctl start rsync Job for rsync.service failed because the control process exited with error code. See "systemctl status rsync.service" and "journalctl -xe" for details. [root@laptop system]# echo $? 1 [root@laptop system]#
Да, можно сказать, что это костыль. Я спорить не буду )))
Laney1
17.08.2016 20:16+4мне кажется, тут виноват не systemd, а вы, потому не читаете документацию. Если хотите получать ошибку при отсутствующем файле rsyncd.conf, то надо прописать не «ConditionPathExists», а «AssertPathExists».
inkvizitor68sl
17.08.2016 20:32-3Это дефолтный unit из дебиана, я его не писал.
Если основные мейнтейнеры дебиана (а rsync — один из core-пакетов) ошибаются в этом инструменте, чего ждать от обычных людей, которые доки читают всегда по диагонали?Laney1
17.08.2016 20:51+1откуда вы знаете, что это ошибка мейнтейнера? Вполне возможно, что его ожидания просто не совпали с вашими. В любом случае, systemd тут не при чем.
Кстати, я тоже считаю себя обычным человеком, никогда не админившим ничего крупнее своего ноутбука и писавшим для systemd только простейшие запускалки всяких webpack-ов, чтобы их вывод не забивал консоль. Однако мне хватило двух минут гугления, чтобы разобраться, в чем тут дело. Так что это не бог весть какая проблема.
Balek
17.08.2016 21:02+6Если основные мейнтейнеры дебиана не справляются с написанием 7 строк конфига, то как можно от них ожидать, что они справятся с написанием скрипта на сотни строк? Хотя, на мой взгляд, с задачей они справились на отлично. rsync работает не только в серверном, но и в клиентском режиме. Зачем вам в логах лишняя ошибка при загрузке, если rsync установлен только для клиентского режима? Как только вы создатите конфиг демона, сервис начнет стартовать. Что может быть логичнее, не представляю.
Prototik
18.08.2016 00:05Демон, всё-таки, должен быть запущен явно (systemctl enable rsyncd), этот юнит из дебиана действительно немного корявый, как по мне. Либо заменить Condition на Assert, либо убрать его к чертям собачим — сервис в любом случае завалится.
Balek
18.08.2016 14:08enable же не нужно делать вручную для apache, postfix и прочих. Хотя, конечно, это вкусовщина. Я немного скатился в троллинг, говоря, что такое поведение «логичнее». И так, и так все вполне логично.
cyberdimk
17.08.2016 18:49-3домашний админ — на роутере hardened gentoo (без SE) на рабочей дизайнерской машине просто gentoo с open-rc — приложения запускаются, за сеть спокоен, да — нет гнома3 и прочей «графы», xfce устраивает… без systemd.
ITLav
17.08.2016 19:32Есть такая штука — EPM
http://wiki.etersoft.ru/Epm
помимо управления пакетами, там есть команда serv, которая
обеспечивает управление сервисами вне зависимости от системы.
Возможно, это то, что вы искали.dmitry_ch
18.08.2016 01:29+1Интересно, спасибо!
Но вот смотрю я на EPM, вижу (уже очередной) костыль, который сглаживает острые углы синтаксисов и позволяет делать много чего однообразно. Но при этом с ощущением, что на дворе — 2006 год, а то и 1996.
Т.е. я понимаю, что написать epm -i (package) логично, но почему нельзя было написать для людей epm install (package) — не очень понимаю. Да, написать -i быстрее, но зато с install меньший шанс промахнуться при вводе довольно важной (и опасной, по степени влияния на систему) команды. При этом «длинная» команда среди списка управления пакетами есть, правда — одна, а именно epm upgrade. Т.е. автор изложенное выше как-то постиг, но «было уже поздно»?
Зато, подозреваю, все это упирается в те «милые» мелочи, из-за которых кому-то нравится (а может — и «нравится») aptitude, а кому-то yum. Получаем наименьший общий знаменатель, чтобы в любой системе сделать необходимый минимум операций.
Тот факт, что EPM не входит в состав всех дистрибутивов штатно (хотя бы через подключение репозитария, как тот же nginx), что автоматически добавляет некоторые вопросы по поводу автоматизации установки и обновления его — никак не улучшают отношение к возможности его использования.
Зато сразу могу обратную «прелесть» назвать: имеем мы с вами, скажем, 30 серверов, на 17 из них Debian, на 13 — Centos. Вам нужно на всех поставить одинаковый софт, да с зависимостями. Вроде бы пишем по шпаргалке, epm -i, а вот дальше нужно указать имя пакета, и тут наступает вопрос — оно может быть разным в разных дистрибутивах. Запустить тот же Apache в Debinan — это /etc/init.d/apache2, в Centos — /etc/init.d/httpd. И тут мы либо добавим в EPM таблицу соответствия, что, мол, при serv apache на самом деле дергается тот или иной скрипт запуска апача, либо делаем в своих скриптах кучу ветвлений — и тогде непонятно, зачем нам epm в роли прослойки.
Тем более что те, кто обслуживают сервера, обычно сидят на одном каком-то дистре (может, на разных версиях, но уж везде пишут либо aptitude, либо yum), и проблема, что люди забывают, что же писать на конкретной машине — не самая насущная. А если человеку досталось наследство, где есть «всего понемножку» (давайте к 30 упомянутым машинам добавим еще парочки «солярок», и несколько FreeBSD разных версий) — то EPM либо не осилит, либо станет умнее нас с вами, и станет понимать человеческую речь, что-то вроде «epm apache won't start, please fix it» ))ITLav
18.08.2016 05:30Если называете очередным костылём, поделитесь, какие были ещё, я не видел.
> почему нельзя было написать для людей epm install
epm поддерживает все привычные варианты, для людей, имеющих опыт работы с любым ПМ. Это видно в выводе epm --help
Так, установить пакет можно командами epmi, epm -i, epm install.
Ситуацию с вхождением EPM в дистрибутивы исправим, если в этом видится смысл.
Про разные названия пакетов и сервисов вы правы. Но это просто ещё не доделанная часть. И, всё же, epm для людей в первую очередь, а во вторую для скриптов.
> те, кто обслуживают сервера, обычно сидят на одном каком-то дистре
Мне и моим скриптам приходится обслуживать несколько десятков дистрибутив, так что я понимаю этих людей.
> добавим еще парочки «солярок», и несколько FreeBSD разных версий
На всякий скажу, что epm работает и на Solaris, и на FreeBSD, и на OpenWRT, и немного на на MacOS и Android.
По сути важная проблема одна — названия. И тут я жду совета.
prometheus_ru
18.08.2016 11:15Спасибо за ссылку. Увы, не уверен, поскольку я предпочитаю автоматизироваться через chef и использовать все-таки нативные инструменты.
По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что-то сделать. Я не вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно.
Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты накатить, разбирайся как».
Но за ссылку еще раз спасибо, интересно.
k0ldbl00d
17.08.2016 20:12+1В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта так и не перешло на него!
Этого не случилось, как минимум, потому что Linux это не только Ubuntu. Ну а когда все поняли что уже надо бы что-то сделать, systemd показался сообществу более перспективным.prometheus_ru
18.08.2016 11:17А я говорю конкретно про Ubuntu. Upstart был там аж с 2006 на подтанцовках, а с 2009 уже во все поля. За пять лет ничего толком не изменилось, в 14.04 Apache так и стартует до сих пор из SysV.
Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.grossws
18.08.2016 17:40+1Из-за этого были прекрасные баги с, например, убийством mongodb, когда при ребуте их sysv'шные скрипты убивали всё через небольшое время (то ли 2 минуты, то ли 15 секунд между
SIGTERMиSIGKILL) несмотря на timeout'ы в upstart-скриптах. Для меня это был один из факторов отказа от ubuntu server lts (тогда была 10.04) и ухода на centos.symbix
18.08.2016 22:15+1Ай, я со времен того же 10.04 собираю почти важные пакеты (для разных серверных демонов там) самостоятельно.
Все эти дела в ubuntu прилетают из debian-а практически без изменений, а там такое… Нет, правда. Если у вас все работает и вас все устраивает, в deb-src просто не смотрите, никогда не смотрите. Не надо.
У centos (точнее, у RHEL) другая проблема — там штатно вообще ничего нет, а то, что есть, устарело еще до релиза. Понятно, что все решается подключением всяких epel-ов, но это уже другой дистрибутив получается.grossws
19.08.2016 01:45По сути да, rhel/centos без epel (или ещё хуже rpmforge) не очень приятен, если не поддерживать пачку пакетов самостоятельно. Сейчас, в принципе, есть copr, если не лень поддерживать спеки.
Я для сборки своих пакетов использую свой же docker-контейнер с необходимым окружением. В итоге, сборка выглядит довольно просто:
docker run -it --rm -v <base-dir>:/data grossws/makerpm:7 pkg1.spec path/to/srpm/relative/to/<base-dir>/pkg2.src.rpm ...с выхлопом в<base-dir>/REPO/centos/7/x86_64/...(для centos 6 — аналогично). Этот вариант несколько медленнее, чем держать сервер с необходимым окружением, но даёт всегда сборку в чистом окружении.symbix
19.08.2016 02:09+1О, с докером идея годная, надо будет тоже так сделать себе в Ubuntu. Я пока обычным lxc-контейнером обхожусь, который восстанавливаю из копии, если невзначай загадил.
А на rpm и его спеки у меня почему-то аллергия. Объективно вроде все нормально, но как-то не радуют, как те поддельные воздушные шарики. Наверное, моральная травма от старых редхатов без yum: как-то лет 12 назад пришлось самому рекурсивно выкачивать rpm-ки по зависимостям и у меня кончился стек — забыл, что хотел поставить. :)
Saffron
17.08.2016 21:11> Во-вторых, SysV было глубоко плевать на интимную жизнь программ. Он их запускал на старте, но если у тебя что-то не получалось, то это был их личные проблемы. Отлаживать такие вещи, кстати, практически невозможно. Segmentation fault? Настоящие мужчины пишут программы, которые запускаются с первого раза и не сегфолтят, слабак.
А почему init должен заботиться о личной жизни программ? Для этого существуют специализированные бэби-ситтеры: олдовый daemon tools или хипстерский monit. Принцип unix-way: делай своё дело хорошо, и дай остальным возможность делать своё дело. Но даже если вы страдаете от NIH синдрома, не обязательно встраивать свой daemon tools в init, его можно выпустить как отдельное приложение.
Кстати, в обзоре разных init программ, вы забыли о том, что init — это по сути простой скрипт, некоторые пишут полностью кастомный скрипт запуска системы на каком-нибудь баше или ещё лучше — на си. Если важна скорость запуска, а система давно уже не меняется с точки зрения добавления/удаления демонов, то вполне себе выбор.
> Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.
Такое впечатление, что вы не подозреваете о существовании альтернативных точек зрения. Например, о том, что софт не всегда запускается инитом. Ну там можно запускать отладочную версию. Или пользователь может запускать демон в своих собственных, а не системных, целях. Опять же демону лучше знать, как он инициализируется, ресетит полномочия, и почему ему удобнее демонизироваться.
Кстати о systemd, авторы не только переизобрели daemon tools, но ещё и inetd до кучи.khim
17.08.2016 22:09+2А почему init должен заботиться о личной жизни программ?
Потому что больше некому? UNIX, видите ли, так устроен, что по-хорошему это может сделать только init. И, что самое итересное, когда-то давным-давно SysV init именно это и делал. Там, конечно, не без подводных камней было, но… по первоначальной задумке SysV init должен был это делать! Однако схема оказалась недостаточно гибкой и вместо того, чтобы довести её «до ума» она была обвешали невероятным количеством костылей.
Принцип unix-way: делай своё дело хорошо, и дай остальным возможность делать своё дело.
Золотые слова! Проблема в том, что SysV init делает своё дело плохо!
Кстати о systemd, авторы не только переизобрели daemon tools, но ещё и inetd до кучи.
А что в этом плохого? Обе эти программы существуют потому, что SysV init не справляется со взятыми на себя обязанностями. systemd — справляется, в нём в PID1 вернули то, что там всегда должно было быть! Так что костыли — можно выбросить за ненадобностью.Saffron
18.08.2016 00:35-2> Золотые слова! Проблема в том, что SysV init делает своё дело плохо!
А что она делает плохо? Программы запускаются? Запускаются. Ну по крайней мере на нашей стороне пуля вылетела нормально. С чего вы взяли, что ответственностью init является какой-то там системный мониторинг? Init — pid 1, он должен быть простым как автомат калашникова. Со всем остальным могут справиться pid > 1 (их если что и перезапустить не жалко). Я, кстати, втречал системный софт, который имеет встроенный бэби-ситтер, зачем им тогда ещё один на стороне инита нужен?
> systemd — справляется
systemd — это Nero (который болванки записывает) мира линукс. Безумный комбайнер, который умеет всё. Чуть ли не дистрибутив одной программой. Никто не спорит, что можно отлить всё в монолите, но зачем? Какова практическая ценность?prometheus_ru
18.08.2016 00:47+2Видите ли, логика простая. Один бэби-ситтер для всех лучше, чем каждый софт со своим бэби-ситтером, это раз. Далее, не все бэби-ситтеры одинаково хороши, это два. Разработчик должен писать софт, а не бэби-ситтеров, это три.
systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.Saffron
18.08.2016 03:40-1> Один бэби-ситтер для всех лучше, чем каждый софт со своим бэби-ситтером, это раз.
Не факт. Единая точка отказа. Вон разработчики хрома пришли к тому, что на каждую вкладку надо запускать свой процесс. А я так уже давно делал на fluxbox, там можно любые приложения объединять во вкладки. В том числе uzbl (ныне покойный). Та же самая джава запускает по виртуальной машине на каждый процесс (у них такая самодиагностика, что помощнее бэби-ситтера будет). Так что чем плохо иметь несколько инстансов бэби-ситтера — не ясно.
> Далее, не все бэби-ситтеры одинаково хороши, это два
Если вас как разработчиков системы это волнует — напишите свой. Только не надо его встраивать в init, пусть будет независимой системой.
> Разработчик должен писать софт, а не бэби-ситтеров, это три.
Так есть же готовые. Потом, если у софта требования по надёжности работы в много девяток, то кастомный бэби-ситтер заточенный конкретно под этот софт — естественное решение.
> Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
Вопрос модульности не в дроблении, а во взаимозаменяемости. Есть хоть один компонент, который можно заменить на сторонний? Не теоретически, а на практике, так чтобы этот сторонний компонент существовал. Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.prometheus_ru
18.08.2016 10:32+4Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.
systemd состоит из разных бинарей. Никто не мешает Вам написать свой. Просто ныть о модульности любят, обычно, те, кто ничего писать и не собирался, а просто повторяет «монолитно это плохо», как мантру.
prometheus_ru
18.08.2016 11:18+1И про единую точку отказа, простите, забыл сразу.
init — всегда единая точка отказа. Коряво собранный initramfs — единая точка отказа. Корявый модуль ядра — единая точка отказа.
Если проблемы у init, то все остальное уже неважно. И эта логика в systemd хороша.
prometheus_ru
17.08.2016 22:45inetd вообще на сегодняшний день не нужен никому, придуман был от бедности, поскольку latency была большой.
Я ни разу не забывал, что init — это простой скрипт, ну и что? Это как-то уменьшает его недостатки?
Ну и про альтернативные точки зрения. Для отладки можно (и нужно) запускать демон самому с нужной командной строкой. В чем проблема?
grossws
17.08.2016 22:46init — это по сути простой скрипт
Ага, написанный на Си. Вы хоть раз в его исходники заглядывали? Или исходники upstart'а?
prometheus_ru
17.08.2016 22:47Автор комментария, думаю, говорил об init, который из initramfs.
grossws
17.08.2016 22:52Он же тоже через rc.local обычно дёргается?
edited: имелось ввиду на sysv системах
Saffron
18.08.2016 01:46У вас на Си, у меня — на баше. Init — это что ядру будет передано как init, ядро честно исполнит любой скрипт. Подразумевается, что этот скрипт умеет запускать систему. Мне вот пришлось копаться в исходниках, когда lvm не хотел дружить с dmraid, так что я точно знаю, что это баш.
Причём тут исходники upstart'a? С чего вы взяли, что для успешного запуска линукса необходим монстр вроде upstart, systemd или openrc? Любой скрипт сойдёт. Я читал, как энтузиасты сваяли init скрипт на common lisp, а потом сидели в нём через удалённый отладчик, который REPL. Забавно, но не практично. Продвинутые init-системы — это вопрос удобства конечного пользователя, а не суровой необходимости.
andvgal
17.08.2016 21:16+5Думаю в статье не указано самое главное, а именно поддержка cgroup и limits в systemd из коробки, не говоря уже о namespaces.
Теперь «родные» сервисы крайне легко разграничить так, чтобы они не мешали другим в рамках той же системы. Например, действительно без войны ресурсов удаётся запускать несколько сервисов баз данных или JVM на одной системе без контейнеров или виртуалок.
Автоматически рестарт помог избавиться от костылей на daemontools или runit.
P.S. Сам года два противился systemd пока не познал весь его дзен.prometheus_ru
17.08.2016 22:39+1Я знаю про cgroups и limits, но в рамках статьи, в масштабах зоопарка старта обычных служб счел это не таким уж важным. В проде больше всего наблюдаю cgroups и limits как раз для JVM, но у меня его в проде нет.
zunkree
18.08.2016 01:03Откройте для себя OpenRC, где так же есть поддержка cgroups и limits из коробки.
AVX
17.08.2016 21:22Вначале было просто: загрузчик — ОС — программы
Потом так: загрузчик — ОС — система запуска — программы
И если раньше было как бы понятно, что ОС в целом разрабатывает команда разработчиков конкретного дистрибутива, которая и заботится о системе управления пакетами программ, запуском и прочими вещами; то теперь система запуска явно выделилась в нечто отдельное, за которое вроде никто и не отвечает. Создатели systemd как бы не отвечают за unit файлы, а предоставляют это разработчикам дистрибутивов и программ. Разработчики дистрибутивов при всём желании не смогут для кучи программ это всё перепахать, а разработчики программ плевать хотели на то, как и кто их будет запускать, и уж тем более про какой-то стандарт запуска-остановки-рестарта-(чего-угодно-ещё).
Сколько не смотрел — во всех дистрибутивах такой бардак, мешанина из sysv, upstart и systemd. Для серверов, по большому счёту, systemd не особо и надо, а вот для всяких мобильных устройств, типа ноутбуков и планшетов и смартфонов (и прочего барахла) — будет сильно заметна разница — в одном случае загрузка за 3 секунды, в другом за 15с.prometheus_ru
17.08.2016 22:40+2Поверьте, systemd и наблюдение за службами еще как надо на серверах. Потому что хочется быть уверенным, что если служба вылетит с segmentation fault или еще как, будет кому подхватить упавшее знамя.
grossws
17.08.2016 22:49+1В rhel/centos 7 бардака не наблюдается. В 6 — было выше крыши, из-за соседства upstart и sysv.
larrabee
18.08.2016 00:17+2В CentOS 7 никакого бардака
ll /etc/init.d/ -rw-r--r-- 1 root root 13948 Sep 16 2015 functions -rwxr-xr-x 1 root root 2989 Sep 16 2015 netconsole -rwxr-xr-x 1 root root 6630 Sep 16 2015 network -rwxr-xr-x 1 root root 8953 May 13 13:55 td-agent
Системных всего 2 скрипта, остальное зависит от мейнтейнеров пакета. На арче вообще никаких инит скриптов нет, мейнтейнеры справляются и пишут юниты для всего софта. Системд убрал много боли. Теперь, что бы понять как запускается демон можно просмотреть 5-15 строк кода, весто инит скрипта на две сотни строк, поправить или написать свой юнит дело 5 минут.AVX
18.08.2016 08:44Спасибо, 7 не смотрел, буду изучать. Или всё-таки надо ещё раз арч поизучать (очень уж их вики хороша, на все вопросы можно найти ответ). Идеология самого системд мне нравится, но как её реализуют во многих дистрибутивах — ужас. Надеюсь, что это просто переходный период, пока нужна совместимость со старым софтом (который всё ещё написан с ориентацией на sysv).
grossws
18.08.2016 17:48+1Как показывает практика (rhel/centos 7 и arch, плюс куча своего софта с переходом
upstart->systemd), софт почти всегда без проблем оборачивается в unit'ы без каких-либо сложностей. Причём в fedora/rhel мейнтейнеры осилили написать unit-файлы для подавляющей части софта в репозиториях, и мне абсолютно непонятно почему мейтейнеры debian'а не смогли использовать эти юнит-файлы с минимальными изменениями (типа использования/etc/default/вместо/etc/sysconfig/и подобной мелочёвки).
При этом написать корректный юнит проще, чем корректный init-скрипт, особенно если init-скрипт должен поддерживать несколько дистрибутивов.
symbix
18.08.2016 22:24+1В rhel/centos так себе, grep ExecStartPre находит много веселья. Вот в arch — почти ничего.
А в дебиане, мне кажется, мейнтенеры таким образом протестуют против навязанного им systemd, другого объяснения у меня нет :)prometheus_ru
18.08.2016 23:07Золотые слова про протест :)
grossws
19.08.2016 01:48Видимо, они точно так же протестовали против upstart'а. А ещё раньше — против нормальных sysv init-скриптов.
grossws
19.08.2016 01:51А что страшного вы нашли в
ExecStartPre? Погрепал на паре своих серваков и ничего пугающего не обнаружил: проверка конфигов, создание маркерных файлов, создание необходимых директорий + chown + chmod, всякиеdocker create(ибо часть софта у меня в контейнерах и вExecStartPreконтейнер создаётся, вExecStartделаетсяdocker start -a ..., а вExecStopPostделаетdocker rm -f ...).
4144
20.08.2016 03:39Debian пока еще поддерживает более одного типа init'а. Хотя systemd поумолчанию.
Если писать скрипты для каждого инита, это будет слишком много. Видимо поэтому маинтейнеры выбирают те скрипты, которые везде будут работать.
kay
17.08.2016 21:37Так и не понял на кого жалуется автор. На разработчиков systemd или на разработчиков ПО, которые пилят что-то вроде:
ExecStart=/etc/init.d/service start ExecStop=/etc/init.d/service stop
Если последнее, то возможно это даже не разработчики, а мантейнеры пакетов.
prometheus_ru
17.08.2016 22:42Тут виноваты и те, и другие.
Разработчикам пофиг, они только SysV поддерживают. Мэйнтейнеры пакетов обычно кладут на необходимость создания unit-файлов, ведь SysV же работает.
Замкнутый круг.
gold_user
17.08.2016 22:40OpenRC не хватает в этом списке. Как не крути, а он доступен, разрабатывается и списывать его со счетов не вижу повода. Если у вас иное мнение — не против выслушать его.
prometheus_ru
17.08.2016 22:41Я, увы, не профессионал в этой области, поскольку специализируюсь на Debian/Ubuntu. Не знаком с реализациями OpenRC под них.
gold_user
18.08.2016 08:07Увы и ах, но от статьи я ожидал большего. Далеко не полно раскрыта тема, даже про systemd. Для сравнения,
статья 2011 годаhttps://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/comparativo_upstart_sysvinit_systemd_openrc?lang=ruAVX
18.08.2016 08:48что мне даст выигрыш во времени при старте
Например, включаете телефон, и он загружается 40 секунд… или — 5 секунд. Есть разница? Другой пример — видеорегистратор — задержка включения в полминуты уже очень неудобна, гораздо лучше когда запустится практически сразу. Для одноядерных процессоров разницы по времени может и не быть, но сейчас чуть ли не в часах 2 и более ядра пихают.
prometheus_ru
18.08.2016 10:33+3Вы простите, но я не писал статью с обзором про systemd, таких обзоров на Хабре тысячи.
Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду причин. О которых я в полушутливой форме рассказал.
daan
17.08.2016 22:40-5Буду краток: ненавижу systemd.
Запилить монстра который заставил изменить привычный уклад жизни админа — достойно порицания.prometheus_ru
17.08.2016 22:43+2Поверьте, уклад жизни админа начал меняться еще с Upstart. Потом стал меняться, когда стало понятно, что Debian тоже перейдет на systemd. Возможно, изменится еще раз, но пока systemd обладает всеми шансами на статус нового SysV. Поэтому автору крайне хочется, чтобы systemd стал стандартом у разработчиков софта.
crlam0
18.08.2016 00:29> Поверьте, уклад жизни админа начал меняться еще с Upstart.
Вы забыли уточнить: Debian/Ubuntu админа.grossws
18.08.2016 00:33В rhel6 тоже был upstart, хотя большая часть софта жила на sysv init-скриптах.
crlam0
18.08.2016 00:51Я отвечал prometheus_ru, который чуть выше написал «Я, увы, не профессионал в этой области, поскольку специализируюсь на Debian/Ubuntu».
Но тем не менее: Вы только подтверждаете что с появлением Upstart жизнь админа не менялась, раз в RHEL6 его появление не особо задело.prometheus_ru
18.08.2016 00:52RHEL6 еще как задело. Потому что там наблюдалось примерно то, что сейчас в Ubuntu 16.04. RHEL7 тоже задело, поскольку убежали на systemd.
daan
18.08.2016 12:35-3Upstart это эволюция SysV init scripts.
Systemd — революция.
Привычный уклад — это не застой, а стабильное совершенствование, планомерное движение к лучшему.
Systemd предлагает новую философию, подход и заставляет тратить время на то, что до его прихода уже работало.
symbix
18.08.2016 00:49+1То, что в ubuntu main, кстати, более-менее по upstart-феншую было. Почти все sysv-добро в основном было унаследовано от мейнтенеров дебиана, о которых я, пожалуй, лучше не буду говорить ничего (а ведь и на шелле можно сделать хорошо — см. openrc). И о том, как они внедрили systemd, тоже не будут говорить ничего.
Хороший пример, как надо использовать systemd — Arch.prometheus_ru
18.08.2016 00:51Соглашусь про Arch, там systemd в полной мере и крайне хорош. Увы, Arch как по мне не достает неких LTS-версий, ну уж больно rolling release.
А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить, чтобы для всего более или менее важного запилить скрипты на systemd.symbix
18.08.2016 00:59Что поделать, нет в жизни счастья. Был проект arch-server, но сдох толком не родившись.
dion
18.08.2016 01:26-2Самое хреновое в systemd — если что-то не так, то разобраться просто нереально. У меня вот на ноуте из-за cryptsetup этот systemd тупо висит в попытке перезагрузиться. Как это чинить — я просто ума не приложу… А обычный SysV рабоатет отлично.
L1Ntu
18.08.2016 10:30+7Очень люблю смотреть на вайн «Я уже 15 лет админ, но вот в systemd уже 3 года никак нимагу ничего понять»
Так может, стоит потратить 15 минут своего времени чтобы сесть и разобраться с systemd?
delvin-fil
18.08.2016 10:30Да что же так все привязались к UPSTART? Ну без обнов в Gentoo работает прекрасно SYSV. В чем проблема то?
maledog
18.08.2016 16:16-5Ужос просто. Как же мы жили без systemd? Я вот прекрасно жил — все у меня работало и продолжает работать годами. Пока есть возможность выбора системы инициализации. И гентушники вон живут и BSD. А вот пользователи «попсовых» linux как ничего не учили так ничему и не научатся хоть какой инит им поставь. А все потому что не хотят изучать как это работает внутри. Мои личные претензии к systemd:
1. Прямое нарушение unix-way:
— сложная система по определению не может выполнять хорошо все свои функции.
— стремится заменить собой другие демоны и системы, которые и так прекрасно работали и не имели отшения к init вобще(udev, syslog, ntp, настройки сети, даже патчи в ядро)
2. Внедрение этого «комбайна» делает невозможным существование остальных систем инициализации в принципе. Всем кому он по каким-то причинам не нравится приходится уже внедрять не поддержку альтернативного init, а создавать целые форки дистрибутивов или приписывать костыли-эмуляторы, что ведет к дальнейшей фрагментации мира linux.L1Ntu
18.08.2016 16:32+3Звучит примерно так:
Мои предки тысячелетиями катали квадратным колесом, и продолжают катать!
А вы мне тут рассказываете, что накругломпопсовом колесе — лучше
ПС.
unix тоже сложная система как такова, почему она может выполнять все свои функции хорошо?daan
18.08.2016 16:56-1Завуалированное обвинение в ретроградстве не является доказательством превосходства systemd.
Равно как и обращение к обобщению «unix», в контексте сложности систем.L1Ntu
18.08.2016 17:17+3хочу услышать конкретику, а не плачь аля
«Как же мы раньше жили» или
«да вы не понимаете, вот раньше, раааньше все было тааак хорошо без systemd» или
«systemd не может быть хорошая, потому что она сложная(другая)»
Вот привели тут ntp в пример, говорят что плохо. Ну ок
/usr/bin/timedatectl set-timezone Europe/Moscow /usr/bin/timedatectl set-ntp true /usr/bin/timedatectl status
Что здесь кардинально трагического случилось?
Ах да, вот что: теперь не нужно поднимать ntp демон, просто для того чтобы синхронизировать свое время
Но все орут. Какжетаг, systemd теперь и временем управляет?maledog
18.08.2016 18:26-2/usr/bin/timedatectl set-timezone Europe/Moscow
/usr/bin/timedatectl set-ntp true
/usr/bin/timedatectl status
О чем вопрос.
sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
sudo /etc/init.d/ntp restart
Для этого обязательно нужен был systemd?grossws
18.08.2016 18:34+1sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
Это уже в systemd-мире. До этого извращались кто во что горазд
maledog
18.08.2016 18:40Да ладно. А я эту команду даже в LFS встречал и в FreeBSD. А там systemd нет. Вон оно как оказывается…
grossws
18.08.2016 18:52+1В lfs есть вариант с systemd.
Но я говорил про то, что раньше это было дистрозависимо: где-то надо было сделать симлинк, где-то написать
TZ= Europe/Moscow,где-тоTimeZone=, где-тоTIMEZONE=.
В одних дистрибутивах нужно было дополнительно настраивать restrict в
/etc/ntpd.conf, в других — оно уже было в конфиге по умолчанию и т. п.maledog
18.08.2016 19:08Итак, Gentoo, Debian, Ubuntu, Freebsd сколько себя помню всегда зона назначалась через симлинк в любых системах инициализации. Я почти уверен что это работает во всех дистрибутивах linux. То что вы где-то это вписываете в конфиг не значит что симлинк не работает. Unix-way же. Просто какая-то программа парсит конфиг и создает симлинк только и всего. Например в дебиане можно просто создать симлинк, а можно вызвать
dpkg-reconfigure tzdata сути это не меняет.
Раз уж мы заговорили про restrict приведите пример как он реализован в systemd. Я не про включить/выключить, а про скажем ограничить подсети.grossws
18.08.2016 19:42Видимо, всякие вещи типа
tzconfig/tzselect/timeconfigи подобные были просто tui-обёртками надln -sf. Вполне допускаю такую возможность. Естественно, с тех пор, как glibc научилась использовать/etc/localtime. В начале 2000х это было не так, вне мира glibc это может быть не так и поныне.
Раз уж мы заговорили про restrict приведите пример как он реализован в systemd. Я не про включить/выключить, а про скажем ограничить подсети.
В systemd используется
systemd-timesyncd, который является SNTP-клиентом иrestrict— это не про него. Эту тему я поднял, т. к. зоопарк настроек ntpd по умолчанию и явная его избыточность для синхронизации времени привёл к массовому использованию ntp amplification атак.
L1Ntu
18.08.2016 21:07Сравните разницу между
sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
/usr/bin/timedatectl set-timezone Europe/Moscow
Вторая команда намного проще как в запоминании так в провописании
sudo /etc/init.d/ntp restart
До этой команды нужно установить ntp, настроить конфиг, проверить его, и следить за демоном
Сравни это со строчкой /usr/bin/timedatectl set-ntp true после которой тебе вообще ниочем не стоит беспокоитьсяmaledog
18.08.2016 21:56-2Ах ты ж. Конфиг ntp такой сложный — целых 20 строк. Установка ntp в одну команду — это конечно большая сложность. И запоминать нужно.
Хотя… стойте мне ведь тоже нужно запоминать команды и для systemd. А может и нет. Мануалы текстовые устарели. Даешь systemd-mand с переводом всех мануалов в бинарный формат и поддержкой тегов.
maledog
18.08.2016 17:39-4GNU Linux — это набор приложений каждое из которых выполняет одну-две функции.
Вот например tar системное время не устанавливает, и сетью не управляет, функция одна — создать архив. И даже опция выбора компрессии определяется наличием другой внешней программы (gzip например). Оболочка для архиваторов вроде file roller добавляет свой функционал, но не заменяет собой консольные архиваторы и не превращается в «единственный правильный архиватор» частично несовместимый с основными. И что же в этом сложного?
Но мы в древность-то лезть не будем, вот возьмем например WI-FI за работу в режиме клиента отвечает wpa-supplicant для его настройки есть wpa_cli, wicd, network-manager, а если же нам нужно точка доступа есть hostapd. Я могу использовать их могу найти или найти/написать альтернативы. Тот же не network-manager не реализует функционал openvpn/pptp -клиента самостоятельно, хоть и позволяет ими управлять. Если я уберу одну какую-то часть системы или заменю её на другую то это практически не отразится на работоспособности остальных (функционально не связанных) компонентов.
Это unix-way. Так почему systemd это позволено? Почему чтобы убрать systemd я должен примеру переписать половину gnome? Какое отношение desktop-окружение имеет к init? Как при этом уживаются между собой wayland. Xorg гораздо более связаные с desktop? Почему назработчики wayland не запилили свои KMS драйверы? Это же более прогрессивно. И кто сказал, что круглое именно «попсовое» колесо?
Ну и для тех кто не знает для чего fork
Мы разучились писать демоны. Мы не разбираемся как работает система. Мы хотим только запустить экзешник и чтобы все настроилось и заработало. С такими запросами нам дешевле и лучше поставить windows ибо c systemd преимущества linux как стабильность и предсказуемость работы, гибкость и независимость от крупного бизнеса сводятся на нет.gold_user
19.08.2016 05:51-2Золотые слова! За что только заминусовали тебя? Ни одного возражения по существу, но минус, потому что твои слова противоречат их тупизне.
khim
22.08.2016 12:02+2Вам действительно нужны «возражения по сути» к этой чуши? Ладно, потрачу 15 минут. Начнём с центрального утверждения:
Если я уберу одну какую-то часть системы или заменю её на другую то это практически не отразится на работоспособности остальных (функционально не связанных) компонентов.
Ok. Есть у нас священный unix-way, который используется во всех Unix'ах, очевидно. Давайте проверим, что ли. FreeBSD? монилит. NetBSD? монолит. OpenBSD? монилит. Про всякие AIX'ы и HP-UX'ы с Solarias'ами я вообще молчу — там только CD/DVD получить можно, никаких компонентов менять не положено.
Это unix-way.
Да что ж, это, чёрт побери, за unix-way такой, которому ни один Unix не следует? То есть вообще ни один?
А вот такой:
GNU Linux — это набор приложений каждое из которых выполняет одну-две функции. Вот например tar системное время не устанавливает, и сетью не управляет, функция одна — создать архив.
Ну что ж, давайте проверим. Так откуда у нас в системеtar? Из пакета GNU tar, наверное? А вот и нет — из пакета paxutils. Который объединяет в себя исходникиcpio,tarиpax. Пакет coreutils же включает в себя десятки программ, равно как и binutils.
То есть «великий и священный» Unix-way, оказывается, не используется никем вообще, он существует только в больном воображении автора комментария. Удивительно ли, что никто эту чушь комментировать не хочет?
P.S. А unix-way между тем, вполне себе существует. Вот только разделение исходников хотя и позволяет правильно исполнять первую часть (пишите программы, которые делают что-то одно и делают это хорошо), но резко усложняют вторую (пишите программы, которые бы работали вместе). Потому-то все хорошо работающие программы (в том числе и systemd) используют один репозиторий из которого собираются много мелких программ. А вот с третьей (Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс) — тут да, тут systemd немного «отходит от темы», но вот как раз она — наиболее спорна, так как практика показала, что универсальность текстовых потоков, увы, не компенсирует их ненадёжности (сколько багов было посажено в скриптах, пытающихся разобрать логи из-за того что это невозможно сделать надёжно — ни в сказке сказать, ни пером описать).gold_user
22.08.2016 14:58Так откуда у нас в системе tar? Из пакета GNU tar, наверное? А вот и нет — из пакета paxutils.
А не busybox?
https://busybox.net/downloads/BusyBox.html
FreeBSD? монилит. NetBSD? монолит. OpenBSD? монилит.
Поясни. Ссылка мне ни о чем не говорит.khim
22.08.2016 18:27+2А не busybox?
Если busybox, то это уже не GNU/Linux, извините.
https://busybox.net/downloads/BusyBox.html
Поясни. Ссылка мне ни о чем не говорит.
UNIX состоит из отдельных маленьких программ, но все эти программы разрабатываются как часть единого целого. В общем репозитории. Взять какой-нибудь /bin/cat из Netbsd, а /bin/cut из OpenBSD — нельзя. В другой версии их собрать — часто нельзя тоже.
Так разрабатывался UNIX всегда, с момента его создания. Именно и только так можно добиться того, что «маленькие программы», о которых говорит философия UNIX — хорошо работают между собой. И ровно также разрабатывается systemd! Там нет «программы-монстра», там десятки отдельных утилит. Но… в общем репозитории, да.
Вот что является извращением — так это тот идеал, о котором говорит maledog: сотни пакетов, которые плохо согласуются между собой и которые разработчики дистрибутивов вынуждены склеивать между собой с помощью жвачки и изоленты. Получившийся франкенштейн — работает кое-как, но глючит — ужасно. Обновление версий какой-то компоненты превращается в муку.
Нужно ли превращатьsystemdв такое себе дополнение к ядру Linux'а, включающему в себя всё-всё-всё? Наверное всё же не стоит. Крайности — они редко хороши. Но вот тому, что он заменяет собой десятки пакетов — можно только порадоваться. Иметь различия ради различий на ровном месте — большого смысла нет. Если хотите какой-то компонент заменить — ну сделайте себе forksystemdи меняейте. Хотя лучше вначале обсудить с разработчикамиsystemd— а вдруг ваша проблема решится добавлением 10 строк кода и они их примут к себе?
Не умножайте сущности без необходимости, ни к чему это!
P.S. Некоторые инженерные решенияsystemdмне самому не очень нравятся, мягко говоря, но пусть лучше так, чем десятки самых разных подходов и гадания на тему «а чегой-то они вот конкретно тут поиспользовали?»
symbix
19.08.2016 14:23+1С десктопом действительно ерунда какая-то, но меня это мало волнует, у меня мак.
А на серверах нормальный инит нужен, это намного удобнее и предсказуемее, чем обвешиваться супервайзорами.
Fork? Fork не для демонизации, на самом деле. Демонизация — это такой старинный трюк, ритуальные приседания, повторяемые в каждой программе. New style daemons — отличная идея.
Я не фанат systemd, мне не нравится, как он написан, upstart мне нравится намного больше. Но в любом случае — это лучше, чем sysv.grossws
19.08.2016 20:00+1upstart за счёт своего event-drived подхода очень неудобен, когда у сервиса есть зависимость от нескольких других.
symbix
20.08.2016 18:18Не очень удобно, да. Но это проблема не подхода в целом (нормальный подход), а частная недоработка, вполне поправимая.
Но сейчас уже все равно смысла нет :)grossws
20.08.2016 18:30IMHO, это архитектурная проблема. Т. е. если у меня сервис
Aзависит отBиCв смысле Requires+After в терминах systemd, то для в случае upstart самое близкое, что можно написать это
start on started B and started C stop on stopping B or stopping C
Если я после этого перезапущу сервис
C, тоAне перезапустится, т. к. не было событияstarted B. Можно, конечно, попытаться сделать eventsourcing с повторением последнего события из каждого источника, но они не всегда идемпотентны. И это, в свою очередь, сломает кучу систем, где использовались свои event'ы.
develop7
18.08.2016 17:40+2сложная система по определению не может выполнять хорошо все свои функции.
и может, и выполняет (достаточно хорошо, то есть)
стремится заменить собой другие демоны и системы, которые и так прекрасно работали и не имели отшения к init вобще(udev, syslog, ntp, настройки сети, даже патчи в ядро)
- у куска кода нет стремлений.
- помянутые демоны и системы поставляются вместе с инитом, а не являются его частью. Вы же понимаете разницу, да? Ведь правда?
- конкретно у journald есть ряд преимуществ над syslog. с другой стороны, абсолютно никто не мешает пользовать systemd и писать логи в syslog.
Внедрение этого «комбайна» делает невозможным существование остальных систем инициализации в принципе.
Время всех рассудит
создавать целые форки дистрибутивов или приписывать костыли-эмуляторы,
«нет ножек — нет мультиков»
что ведет к дальнейшей фрагментации мира linux
пусть цветут сто цветов
grossws
18.08.2016 17:55+1syslog
О, да, прекрасные syslog/rsyslog/syslog-ng. У вас они ни разу не теряли пару-тройку тысяч ключевых для post-mortem анализа сообщений лога в рамках burst'а при аварии? Удобно ли вам пихать в них логи программ, которые про syslog не знают и знать не хотят?
maledog
18.08.2016 18:13-2Уточните. Какие-такие программы, не говоря уж о демонах, не знают про syslog? А что они знают stdout?
grossws
18.08.2016 18:20+2Подавляющее большинство java-программ (если не обёрнуты специальными костылями типа daemon-tools), всё написанное в концепции 12factor, всякие вещи на rails, куча софта на python'е и т. д. и т. п. Обычно они все умеют в stdout и, часто, в файлы в том виде как это принято в соответствующей экосистеме.
maledog
18.08.2016 18:32-1Я вас удивлю, но и в java и ruby и python есть библиотеки для написания демонов и для нормального логирования. Но раз уж вы решили запустить эту программу, systemd не является такой же оберткой? В чем преимущество?
grossws
18.08.2016 18:40+1Расскажите мне про то, как без внешних костылей заставить стороннее java-приложение со сложным запуском писать в syslog, и как завести под него отдельный facility.
Заодно расскажите как на java установить обработчик SIGHUP без внешних костылей и/или нативного кода. Про процесс демонизации даже спрашивать неловко, но можете тоже поведать миру.
maledog
18.08.2016 18:50Без внешних костылей это как? Про daemonize слышали? Или в вашем понимании systemd костылем не является?
SIGHUP то вам зачем? Что программа незнающая про SIGHUP должна сделать при его получении? Чем вам поможет в этом systemd?grossws
18.08.2016 19:06+1Который daemonize? Ссылку, сестра!
Если вы в курсе общепринятой обработки сигналов в *nix-демонах, то знаете, что обычно по SIGHUP переоткрывается файл лога, чтобы можно было его ротировать стандартным logrotate. Без использования внешнего (по отношению к jvm) обработчика можно использовать только внутренние интерфейсы sun/oracle jvm, что делает софт непереносимым. Т. е. нормальная программа, выполняющаяся на jvm, не может обрабатывать SIGHUP, даже если хочет про него узнать.
Systemd/upstart с моей точки зрения является стандартной частью окружения, которая отвечает за управление сервисами.
maledog
18.08.2016 19:21-1М-м Мы уже определились сам процесс sighup не понимает. Что в этом случае systemd делает?
Если дело только в ротации логов, так куча была программ — svlogd, multilog.
Иными словами ничего нового и полезного systemd пока не принес. но многое старое уже поломал. И как люди не умели пользоваться sysv и upstart, так же не будут уметь пользоваться и systemd.grossws
18.08.2016 19:57+1systemd собирает логи процессов (не только того, которым он управляет, но и его дочерних), обогащает метаданными (в т. ч. доверенными типа timestamp'а, pid т. п.) и направляет всё это в journald. Далее оно может единообразно направляться в syslog/logstash/whatever со структурированными метаданными (без развлечений с парсингом логов регулярками). Далее с этим можно работать, выбирая нужную часть лога, например, по unit'у, а не только по имени процесса, как это обычно происходит с syslog.
Если говорить про svlogd, то минимальную функциональность он имеет (и он тоже не unix-way, на который так любят упирать противники systemd). Но сбор логов, скажем, дочерних процессов он не умеет.
multilog не использовал, за него не скажу. В стандартных репозиториях rhel/centos + EPEL его не видел, равно как и runit с его svlogd.
Что именно
systemdполомал? Раз уж вы так упираете на этот тезис.maledog
18.08.2016 22:33-2systemd собирает логи процессов(не только того, которым он управляет, но и его дочерних)
Поправочка. Дочерний процесс может быть вызван без передачи ему stderr и stdout — по умолчанию большинство так и делает. В этом случае systemd ничего не залогирует. Процесс может форкнуться и закрыть stdout. Процесс Может породить дочерний, который может в свою очередь форкнуться. Да масса ситуаций.
Никто никому не мешал запилить syslogd-mysql или syslogd-mongodb просто никому они были не нужны. И тут нате, оказывается бинаные логи — киллерфича systemd.grossws
19.08.2016 02:12+1Дочерний процесс может быть вызван без передачи ему stderr и stdout — по умолчанию большинство так и делает.
По умолчанию так не делают, если не пытаются специально демонизироваться (или недодемонизироваться, как я часто вижу в разных статьях "как сделать демонизацию на языке ..."). Как минимум, потому что это — дополнительные действия. А сам по себе
forkдаёт те же файловые дескрипторы в дочернем процессе (см.man 2 fork).
Никто никому не мешал запилить syslogd-mysql или syslogd-mongodb просто никому они были не нужны. И тут нате, оказывается бинаные логи — киллерфича systemd.
Интересно, а где же в
man 3 syslogнаписано про структурированные логи и наличие доверенных атрибутов? То я вижу там функциюsyslogочень напоминающую кастомныйsprintf(с поддержкой %m вдобавок к обычным квалификаторам printf'а). И как их впихнуть их поддержку, не разломав и не добавив новую функцию?
А, скажем
int sd_journal_send(const char *format, ...);принимает пачку строк форматирования (для каждого поля, которое необходимо вывести), плюс NULL в конце списка varargs:
sd_journal_send("MESSAGE=Hello World, this is PID %lu!", (unsigned long) getpid(), "PRIORITY=%i", LOG_INFO, NULL);maledog
19.08.2016 11:34А сам по себе fork даёт те же файловые дескрипторы в дочернем процессе (см. man 2 fork).
Перечитайте мое сообщение внимательнее. Форкаемся и закрываем stderr, stdin, stdout. Все нет их у дочернего процесса. В этом суть демона. Писать нужно в лог.
Интересно, а где же в man 3 syslog написано про структурированные логи и наличие доверенных атрибутов?
Странные термины. А RFC 5424? Вроде как все структурировано и формализовано.
develop7
18.08.2016 19:20+1- в том, что от его супервайзинга нельзя сбежать ни даблфорком, ни вообще никак
- в том, что он не видит разницы между демоном и не
- в отсутствии необходимости ритуальных приседаний
amarao
Тем, кому кажется, что systemd просто, рекомендую посмотреть на современное устройство ceph. Там темплейты systemd дёргают триггеры upstart, которые инстансируют другие темплейты systemd, которые в свою очередь дёргают другие триггеры udev, которые, в свою очередь, дёргают systemd.
отлаживать это — одно удовольствие.
splav_asv
А в дистрибутивах RH всё так же запутанно?
celebrate
У меня Ceph Jewel на Centos 7, все нормально запускается и останавливается. SysV скриптов я там не наблюдал.
amarao
Так же. Только у меня опечатка — udev там триггерится, а не upstart.
handicraftsman
Костылями попахивает…
evg_krsk
Upstart? Но он же вроде умер. Или это другой Upstart?
amarao
Тьфу. Заговариваюсь. Триггеры udev, разумеется. От чего всё становится всё интереснее.