 39,0 94,9

@prometheus_ru  
 
Пользователь карма рейтинг

 6 86 0 4
Профиль Публикации Комментарии Избранное Подписчики

вчера в 16:01

Администрирование → SysV, Upstart, systemd в роли

ассортимента граблей Debian/Ubuntu
 Системное администрирование*, Серверное администрирование*, DevOps*, *nix*

Знаете, чем я сейчас занимаюсь? Пишу стартовые скрипты для systemd, и это меня бесит. 

Вроде бы как мы берем операционную систему для того, чтобы экономить время на таких вещах. Вроде как пакеты
должны были облегчить нам жизнь. Весьма возможно, что мой выбор операционной системы был плох, но до
сегодняшнего дня жить в области 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=p
ostfwd ­­group=postfwd

Давайте перестанем уже размазывать настройки между /etc/config.conf и /etc/default/service? 

Давайте перестанем пытаться управлять стартом службы при помощи параметра START=yes в /etc/default/service?
Нет, я понимаю, что «xyes» смотрится отличной шуткой, но надоело уже! 

Давайте уже решим, что systemd — он везде. И что под него можно смело адаптироваться. 

К самому себе

Смирись, тряпка, и не ной. Keep calm and systemd.

  systemd, upstart, systemv

   
  —    6,7k  4  5 
  
  
 


карма рейтинг
 @prometheus_ru  39,0   94,9

Реклама помогает поддерживать и развивать наши сервисы 

Подробнее

Реклама

Самое читаемое Администрирование

Сейчас  Сутки  Неделя  Месяц

+19 Как определить уровень ИТ­зрелости своей компании — и какие они бывают
 5,8k   25   8

+19 Debian Linux и Tor за безопасный deb
 7,1k   52   1

+13 Nagios — мониторинг vmware, CMC­TC, Synology, ИБП, принтеров и совсем немного Cisco
 3k   61   7
 +37 SysV, Upstart, systemd в роли ассортимента граблей Debian/Ubuntu
 6,7k   45   106

+14 «Не процессором единым»: Виртуальные GPU
 7,6k   29   1

Комментарии (106)
 amarao  17 августа 2016 в 16:45   +6      

Тем, кому кажется, что systemd просто, рекомендую посмотреть на современное устройство ceph. Там темплейты systemd
дёргают триггеры upstart, которые инстансируют другие темплейты systemd, которые в свою очередь дёргают другие триггеры
udev, которые, в свою очередь, дёргают systemd. 

отлаживать это — одно удовольствие.

  splav_asv  17 августа 2016 в 22:14        ⬆ +1      

А в дистрибутивах RH всё так же запутанно?

 celebrate  17 августа 2016 в 23:42        ⬆ +1      

У меня Ceph Jewel на Centos 7, все нормально запускается и останавливается. SysV скриптов я там не наблюдал.

 handicraftsman  17 августа 2016 в 23:49        ⬆ +1      

Костылями попахивает…

  Loki3000  17 августа 2016 в 17:24   +5      

В защиту SysV хочу сказать, что он предельно прост и понятен широчайшим слоям пользователей. Даже полные ламеры, вроде
меня, способны в кратчайшие сроки, при помощи гугла, форумов и старших товарищей слепить удобоваримый скрипт запуска
демона. Более того, достаточно прозрачен механизм работы: просто посмотрев содержимое каталога, можно понять что и когда
будет запущено. И контрольный в голову: этот скрипт из желудей и веток будет беспроблемно работать годами. А если
перестанет, то его в состоянии будет починить практически любой, кто немного знаком с линуксом. 
В противовес же SysV, чтобы что­то настроить в systemd, нужно освоить мануал на 10 страниц, все эти юниты со своими
конфигами и синтаксисом, этот systemctl с непонятными параметрами… я не админ, мне не нужна эта информация на каждый
день (кстати, сдается мне что админам она тоже нужна далеко не каждый день), мне раз в пять лет надо настроить запуск
демона и забыть про него. Средствами файловой системы это сделать много проще и понятнее. 
Вот лично для меня systemd не несет никаких удобств. Быть может поэтому его и многие другие игнорируют?

  prometheus_ru  17 августа 2016 в 17:27        ⬆ +3      

Прочитайте внимательно. Бывает, что скрипты на SysV стартуют, однако приложение по какой­то причине вываливается на
старте. Что делать? Я понимаю, запустить руками. Но без режима контроля и рестарта многие современные приложения тупо
не работают нормально. 

Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом. 

А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.

  Loki3000  17 августа 2016 в 17:46        ⬆ 0   

Да я прочитал. Да, бывает. Правда, в моей практике приложения падали и при запуске скриптом и при запуске руками, так
что все это достаточно просто диагностировалось. Видимо просто сложных случаев не было. 
Удобоваримый — это тот который, несмотря на всю свою кривизну, выполняет возложенные на него функции. 

Не админу достаточно одну статью прочитать с базисом.

Эх, вашими бы устами… я вот сейчас почитал вводную статью, посмотрел примеры в своей системе. Понял что я по
прежнему не имею представления в каком порядке все это запускается… понял что если вот прямо сейчас я немного
уловил логику конструирования всего этого, то год спустя мне всю процедуру (включая чтение вводной статьи) придется
начинать сначала. 
Вы в статье спрашивали почему все так держатся за SysV? Я ответил почему за него держусь я.

  khim  17 августа 2016 в 19:11        ⬆ +2      

Понял что я по прежнему не имею представления в каком порядке все это запускается…

А почему вы считаете что есть какой­то один порядок и почему вас это вообще волнует? 

Вы когда Makefile пишите тоже пытаетесь вычислить в какой последовательности файлы будут компилироваться? 


   Loki3000  18 августа 2016 в 00:02        ⬆ 0   

какой­то один порядок и почему вас это вообще волнует?

Почти в 100% случаев не волнует. Но я могу себе представить случай, когда надо запустить какой­нибудь условный
торрент­клиент, который будет работать с файлами на смонтированных шарах. Мне кажется логичным, чтобы
сначала запускался скрипт монтирования, а уже потом — приложение, которое с шарами будет работать.
Параллельно их можно выполнить, но кто поручится за результат?

 grossws  18 августа 2016 в 00:21        ⬆ +1      

И для этого в systemd есть зависимости между unit'ами, чего фактически нет в runit, который всякие странные
люди приводят как альтернативу systemd.

Указываете, для вашего условного rtorrent.service Requires=media­share.mount + After=media­
share.mount и всё работает. При попытке запустить rtorrent.service будет монитроваться шара и основной
юнит будет запускаться после, при попытке отмонтирования шары будет останавливаться сервис.

  Loki3000  18 августа 2016 в 09:10        ⬆ 0   

Я прям не знаю, вы все как будто придуриваетесь:) Перечитайте мой первый комментарий: я не админ и не
хочу им быть. Я простой пользователь. И у меня, пользователя, пытаются отнять простой инструмент и дают
взамен сложный. И эта замена мне, пользователю, никаких плюшек не сулит. Это как у среднестатистического
водителя отнять 5­ступенчатую коробку передач и дать ему взамен 25­ступенчатую. Оно может и здорово и на
всякой спецтехнике я встречал нечто подобное, но обычному водителю­то это нафига?

 VBKesha  17 августа 2016 в 17:46        ⬆ 0   

Предположим приложение упало, что сделает systemd? 
Проанализирует ошибку с которой упало приложение и исправит или тупо перезапустит снова? 

  prometheus_ru  17 августа 2016 в 17:54        ⬆ 0   

Для начала, узнает, почему упало. Т.е. если его остановил админ, то перезапускать не надо. 

Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает
делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось. 

Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка
критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли
его перезапускать. С systemd он будет перезапущен без Вас.

 VBKesha  17 августа 2016 в 18:01        ⬆ 0   

Предположим что это не postfix и что то случилось с данными на диске и сервис из за этого падает. А при старте он
жрёт много процессорного времени и снова падает. В итоге из за systemd лежать весь сервер, да так гораздо лучше. 

А для падучих сервисов ну можно расписать скрипт который висит в памяти и сам перезапускает упавший сервис.
Что в своё время я и делал для одного игрового сервиса. 

Я ничего против systemd не имею, но я им и не пользуюсь, однако усложнение системы старта когда не можешь
найти, где, что и как стартует не радует.

  prometheus_ru  17 августа 2016 в 18:03        ⬆ 0   

Нет, вы можете указать, сколько раз пытаться перезапускать. Дефолтных значений типа 5 хватает. 

А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема
поважнее. 

Вы совершенно правы, что произошло усложнение системы старта. Но не из­за systemd, а просто потому, что
жизнь стала такой.

 VBKesha  17 августа 2016 в 18:09        ⬆ 0   

>> А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть
проблема поважнее. 
Вот именно если вылетит мой скрипт то в целом жить можно а если systemd то да жизнь сложней. 

>> Вы совершенно правы, что произошло усложнение системы старта. Но не из­за systemd, а просто потому,
что жизнь стала такой. 
Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны. И за много лет как
я с этим познакомился ничего не поменялось. Всё как то по старому. 
Я не знаю что должен был решить systemd, может по этому и не понимаю зачем он. 


   prometheus_ru  17 августа 2016 в 18:11        ⬆ +1      

Я же еще раз говорю, получается яицо в яице: мы пишем скрипт, который следит за скриптом, который
следит за скриптом. 

У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с
ошибкой. И никак не перезапускалось. И жизнь — боль :)

 VBKesha  17 августа 2016 в 18:13        ⬆ 0   

Ждем когда это случится с systemd и боль вернется.

  4144  18 августа 2016 в 00:50        ⬆ 0   

У других людей было что именно сам монстробразный systemd падал. Т.к. он слишком много делает в init
процессе. 

И как может простой скрипт на баше упасть, и чтобы не упал init и другие процессы? 

 crlam0  17 августа 2016 в 22:36        ⬆ +1      

Очень жаль, что OpenRC практически нигде кроме Gentoo и производных не пытались использовать :( А
ведь в ней реализована и работа с зависимостями, и параллельный запуск (на сколько помню, в тестовом
режиме, но тем не менее), а главное весьма простые и логичные скрипты запуска. Даже контейнеры можно
с ней запускать. Да, по сравнению с SystemD нет работы с cgroups, нет отслеживания запущенных
процессов, но зато это и не такой комбайн, включающий в себя очень много того, что имхо к системе
инициализации отношения или не имеет, или имеет, но очень отдаленное.

 kachsheev  18 августа 2016 в 00:25        ⬆ 0   

В принципе, ничего не мешает использовать её в deb­based дистрибутиве. Не знаю как сейчас, но
раньше она там вполе сносно справлялась с управлением демонами.

 crlam0  18 августа 2016 в 00:40        ⬆ 0   

Я в курсе, так же как и в Gentoo ничего не мешает использовать SystemD. И даже более того: если
мне не изменяет память, в голосовании за новую систему инициализации в Debian мелькала OpenRC.
Но факт остается фактом: в целом неплохое решение осталось нишевым, это и печалит.

  quarckster  17 августа 2016 в 22:36        ⬆ +1      

Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны.

Админу локалхоста наверное больше и не нужно.

 VBKesha  17 августа 2016 в 22:37        ⬆ 0   

Далеко не локалхоста но в целом больше не нужно.

 zunkree  18 августа 2016 в 00:59        ⬆ +1      

Как раз навороченные фичи systemd более востребованы на локалхостах, это именно там часто
меняется конфигурация оборудования, сетей и сервисов. В серверах все много более стабильно и
большинство фичей избыточно.

  UnixMaster  17 августа 2016 в 18:08        ⬆ +1      

А разве при написание «юнита» systemd админ не может указать, чтобы systemd его не перезапускал?
Специально не искал, но как будто бы можно. Я только пару раз автоматизировал старт Java приложений под
systemd и проблем там не увидел, в отличие от SysV. там есть практически все, просто нужно правильно это
испоьзовать.

 VBKesha  17 августа 2016 в 18:12        ⬆ +3      

Админ ленив, чтобы читать мануалы как расписать ещё один скрипт для ещё одной системы старта, которая
моложе чем аптайм его сервера.

  khim  17 августа 2016 в 19:14        ⬆ +2      

Если админ хочет работать только с серврами, который были запущены до появления systemd, то почему
его вообще волнует что происходит в современных дистрибутивах Linux?

  UnixMaster  17 августа 2016 в 19:30        ⬆ 0   

Видимо программисты сами должны писать скрипты запуска для самописных приложений(что
большинство и делает), а админы ленивые и консервативные. И не в их интересах отрываться от
 «важных» задач, чтобы идти в ногу со временем.

 VBKesha  17 августа 2016 в 22:43        ⬆ 0   

Linux используют не только админы. Он сейчас и в embeded распространён. И вот когда попадается
железка на которой стоит systemd(свежие чуть ли не поголовно) и задача стоит вырезать всё лишнее, и
сделать старт максимально быстрым. То тут приходится узнавать что это за хрень и как её есть. Ну или
второй вариант init из busybox и пару простых скриптов. Чтобы не думать какого хрена всё таки
запустился wpa­suplicant хотя ты точно его прибивал.

 dartraiden  17 августа 2016 в 20:11 (комментарий был изменён)         ⬆ +5      

Если админ не хочется развиваться, идти в ногу со временем, и поглядывать на новые веяния — это его
выбор. Но ничего удивительного, что это путь к профессиональному застою со всеми вытекающими
последствиями. 

В некоторые профессиях (например, бухгалтерское дело) без постоянного отслеживания изменений и
нововведений вообще работать невозможно. Попробуйте в 2016 году вести бухучет по нормативам 2000
года…

  mrak_san  17 августа 2016 в 17:31   0   

все сделано для людей…

  inkvizitor68sl  17 августа 2016 в 17:40   –2      

Всё, что я думаю о systemd в одной картинке — https://pbs.twimg.com/media/ChIcfpoXEAAPgFN.jpg

  prometheus_ru  17 августа 2016 в 17:43        ⬆ +1      

Вы привели отличный пример уробороса. Автор пытается рестартовать службу при помощи /etc/init.d/service, что по сути
работать не должно. 

Однако в системе кто­то об этом побеспокоился и сделал велосипед /etc/init.d/service ­> systemd, но что­то пошло не так,
поскольку надо смотреть, как написан .service­файл.

  inkvizitor68sl  17 августа 2016 в 17:48 (комментарий был изменён)         ⬆ –2      

> что по сути работать не должно. 
Вообще отношения к делу не имеет.  

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 августа 2016 в 17:55        ⬆ +2      

systemctl cat rsync в студию, покажите. Для начала разберемся, как оно запускается. Но /etc/init.d/service с systemd надо
забыть.

  inkvizitor68sl  17 августа 2016 в 18:12        ⬆ 0   

root@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.target 

  prometheus_ru  17 августа 2016 в 18:30        ⬆ +1      
Сразу по косякам. 

­­daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все
хорошо. Type= не указано, поэтому systemd считает, что это simple. 

1. Я бы попробовал добавить Type=forking в секцию Service. 

2. У rsync очень особое понимание того, как оно запущено. ­­daemon обозначает не просто fork, а еще пояснение,
что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так: 

[Service] 
Type=simple 
ExecStart=/usr/bin/rsync

  inkvizitor68sl  17 августа 2016 в 18:36        ⬆ 0   

Type=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 августа 2016 в 18:39        ⬆ 0   

Он, судя по всему, не пытается. Из документации следует, что если эта проверка фейлится, то 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 августа 2016 в 18:42        ⬆ 0   

Я и говорю — к черту это нелогичное поделие не нужно. Поэтому никто и не торопится переезжать.

  prometheus_ru  17 августа 2016 в 18:44        ⬆ +2      

Так логично же, юнит в порядке, он без ошибок, просто не сконфигурирован сейчас. Поэтому и не
запустился. 

Я не понимаю, что здесь нелогичного?

  inkvizitor68sl  17 августа 2016 в 18:57        ⬆ +2      

Пользователю сообщить об стоит, вестимо?

  bobelev  17 августа 2016 в 18:39        ⬆ 0   

А что пишет systemctl status rsync?

  inkvizitor68sl  17 августа 2016 в 18:40        ⬆ 0   

● rsync.service — fast remote file copy program daemon 
Loaded: loaded (/lib/systemd/system/rsync.service; disabled) 
Active: inactive (dead) 

  prometheus_ru  17 августа 2016 в 18:41        ⬆ 0   

Ваш коммент ниже подтверждает, что все именно так, как в документации :)


   inkvizitor68sl  17 августа 2016 в 18:42        ⬆ –2      

Вот только приложение не запустилось, а я об этом ничего не узнал. А что там в документации — мне в
целом наплевать, как пользователю ;)

  masai  17 августа 2016 в 21:28        ⬆ 0   

Если хотите, чтобы не запускалось, то используйте AssertPathExists= вместо
ConditionPathExists=. Или я неправильно понимаю суть проблемы?

  UnixMaster  17 августа 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 августа 2016 в 20:16        ⬆ +3      

мне кажется, тут виноват не systemd, а вы, потому не читаете документацию. Если хотите получать ошибку при отсутствующем
файле rsyncd.conf, то надо прописать не «ConditionPathExists», а «AssertPathExists».

  inkvizitor68sl  17 августа 2016 в 20:32        ⬆ –1      

Это дефолтный unit из дебиана, я его не писал.  
Если основные мейнтейнеры дебиана (а rsync — один из core­пакетов) ошибаются в этом инструменте, чего ждать от
обычных людей, которые доки читают всегда по диагонали?

  Laney1  17 августа 2016 в 20:51        ⬆ +1      

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

Кстати, я тоже считаю себя обычным человеком, никогда не админившим ничего крупнее своего ноутбука и писавшим
для systemd только простейшие запускалки всяких webpack­ов, чтобы их вывод не забивал консоль. Однако мне хватило
двух минут гугления, чтобы разобраться, в чем тут дело. Так что это не бог весть какая проблема.

  Balek  17 августа 2016 в 21:02        ⬆ +6      

Если основные мейнтейнеры дебиана не справляются с написанием 7 строк конфига, то как можно от них ожидать, что
они справятся с написанием скрипта на сотни строк? Хотя, на мой взгляд, с задачей они справились на отлично. rsync
работает не только в серверном, но и в клиентском режиме. Зачем вам в логах лишняя ошибка при загрузке, если rsync
установлен только для клиентского режима? Как только вы создатите конфиг демона, сервис начнет стартовать. Что
может быть логичнее, не представляю.

 Prototik  18 августа 2016 в 00:05        ⬆ 0   

Демон, всё­таки, должен быть запущен явно (systemctl enable rsyncd), этот юнит из дебиана действительно немного
корявый, как по мне. Либо заменить Condition на Assert, либо убрать его к чертям собачим — сервис в любом случае
завалится.

  cyberdimk  17 августа 2016 в 18:49   –2      

домашний админ — на роутере hardened gentoo (без SE) на рабочей дизайнерской машине просто gentoo с open­rc —
приложения запускаются, за сеть спокоен, да — нет гнома3 и прочей «графы», xfce устраивает… без systemd.


  ITLav  17 августа 2016 в 19:32   0   

Есть такая штука — EPM 
http://wiki.etersoft.ru/Epm 
помимо управления пакетами, там есть команда serv, которая 
обеспечивает управление сервисами вне зависимости от системы. 
Возможно, это то, что вы искали. 

  dmitry_ch  18 августа 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 августа 2016 в 05:30        ⬆ 0   

Если называете очередным костылём, поделитесь, какие были ещё, я не видел. 
> почему нельзя было написать для людей epm install 
epm поддерживает все привычные варианты, для людей, имеющих опыт работы с любым ПМ. Это видно в выводе epm ­­
help 
Так, установить пакет можно командами epmi, epm ­i, epm install. 

Ситуацию с вхождением EPM в дистрибутивы исправим, если в этом видится смысл. 

Про разные названия пакетов и сервисов вы правы. Но это просто ещё не доделанная часть. И, всё же, epm для людей в
первую очередь, а во вторую для скриптов. 

> те, кто обслуживают сервера, обычно сидят на одном каком­то дистре 
Мне и моим скриптам приходится обслуживать несколько десятков дистрибутив, так что я понимаю этих людей. 

> добавим еще парочки «солярок», и несколько FreeBSD разных версий 
На всякий скажу, что epm работает и на Solaris, и на FreeBSD, и на OpenWRT, и немного на на MacOS и Android. 

По сути важная проблема одна — названия. И тут я жду совета. 

  prometheus_ru  18 августа 2016 в 11:15        ⬆ 0   

Спасибо за ссылку. Увы, не уверен, поскольку я предпочитаю автоматизироваться через chef и использовать все­таки
нативные инструменты. 

По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что­то сделать. Я не
вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно. 

Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много
свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты
накатить, разбирайся как». 

Но за ссылку еще раз спасибо, интересно.

 k0ldbl00d  17 августа 2016 в 20:12 (комментарий был изменён)    +1      
 В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта
так и не перешло на него!

Этого не случилось, как минимум, потому что Linux это не только Ubuntu. Ну а когда все поняли что уже надо бы что­то сделать,
systemd показался сообществу более перспективным.

  prometheus_ru  18 августа 2016 в 11:17        ⬆ 0   

А я говорю конкретно про Ubuntu. Upstart был там аж с 2006 на подтанцовках, а с 2009 уже во все поля. За пять лет ничего
толком не изменилось, в 14.04 Apache так и стартует до сих пор из SysV. 

Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться
для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.

  Saffron  17 августа 2016 в 21:11   0   

> Во­вторых, 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 августа 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 августа 2016 в 00:35        ⬆ –2      

> Золотые слова! Проблема в том, что SysV init делает своё дело плохо! 

А что она делает плохо? Программы запускаются? Запускаются. Ну по крайней мере на нашей стороне пуля вылетела
нормально. С чего вы взяли, что ответственностью init является какой­то там системный мониторинг? Init — pid 1, он
должен быть простым как автомат калашникова. Со всем остальным могут справиться pid > 1 (их если что и перезапустить
не жалко). Я, кстати, втречал системный софт, который имеет встроенный бэби­ситтер, зачем им тогда ещё один на стороне
инита нужен? 

> systemd — справляется 

systemd — это Nero (который болванки записывает) мира линукс. Безумный комбайнер, который умеет всё. Чуть ли не
дистрибутив одной программой. Никто не спорит, что можно отлить всё в монолите, но зачем? Какова практическая
ценность?

  prometheus_ru  18 августа 2016 в 00:47        ⬆ +2      
 Видите ли, логика простая. Один бэби­ситтер для всех лучше, чем каждый софт со своим бэби­ситтером, это раз. Далее,
не все бэби­ситтеры одинаково хороши, это два. Разработчик должен писать софт, а не бэби­ситтеров, это три. 

systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно
преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.

  Saffron  18 августа 2016 в 03:40 (комментарий был изменён)         ⬆ –1      

> Один бэби­ситтер для всех лучше, чем каждый софт со своим бэби­ситтером, это раз. 

Не факт. Единая точка отказа. Вон разработчики хрома пришли к тому, что на каждую вкладку надо запускать свой
процесс. А я так уже давно делал на fluxbox, там можно любые приложения объединять во вкладки. В том числе uzbl
(ныне покойный). Та же самая джава запускает по виртуальной машине на каждый процесс (у них такая
самодиагностика, что помощнее бэби­ситтера будет). Так что чем плохо иметь несколько инстансов бэби­ситтера —
не ясно. 

> Далее, не все бэби­ситтеры одинаково хороши, это два 

Если вас как разработчиков системы это волнует — напишите свой. Только не надо его встраивать в init, пусть будет
независимой системой. 

> Разработчик должен писать софт, а не бэби­ситтеров, это три. 

Так есть же готовые. Потом, если у софта требования по надёжности работы в много девяток, то кастомный бэби­
ситтер заточенный конкретно под этот софт — естественное решение. 

> Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют
между собой.  

Вопрос модульности не в дроблении, а во взаимозаменяемости. Есть хоть один компонент, который можно заменить
на сторонний? Не теоретически, а на практике, так чтобы этот сторонний компонент существовал. Для модульной
системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть
даже разбитая на несколько файлов, останется монолитной.

  prometheus_ru  18 августа 2016 в 10:32        ⬆ +1      

Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый
релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.

systemd состоит из разных бинарей. Никто не мешает Вам написать свой. Просто ныть о модульности любят,
обычно, те, кто ничего писать и не собирался, а просто повторяет «монолитно это плохо», как мантру.

  prometheus_ru  18 августа 2016 в 11:18        ⬆ 0   

И про единую точку отказа, простите, забыл сразу. 

init — всегда единая точка отказа. Коряво собранный initramfs — единая точка отказа. Корявый модуль ядра —
единая точка отказа. 

Если проблемы у init, то все остальное уже неважно. И эта логика в systemd хороша.

  prometheus_ru  17 августа 2016 в 22:45        ⬆ 0   

inetd вообще на сегодняшний день не нужен никому, придуман был от бедности, поскольку latency была большой. 

Я ни разу не забывал, что init — это простой скрипт, ну и что? Это как­то уменьшает его недостатки? 

Ну и про альтернативные точки зрения. Для отладки можно (и нужно) запускать демон самому с нужной командной строкой. В
чем проблема?

 grossws  17 августа 2016 в 22:46        ⬆ 0   

init — это по сути простой скрипт

Ага, написанный на Си. Вы хоть раз в его исходники заглядывали? Или исходники upstart'а?

  prometheus_ru  17 августа 2016 в 22:47        ⬆ 0   

Автор комментария, думаю, говорил об init, который из initramfs.

 grossws  17 августа 2016 в 22:52 (комментарий был изменён)         ⬆ 0   

Он же тоже через rc.local обычно дёргается?
 edited: имелось ввиду на sysv системах

 k0ldbl00d  17 августа 2016 в 23:00        ⬆ 0   

Автор комментария, думаю, говорил о init­скприптах

  Saffron  18 августа 2016 в 01:46        ⬆ 0   

У вас на Си, у меня — на баше. Init — это что ядру будет передано как init, ядро честно исполнит любой скрипт.
Подразумевается, что этот скрипт умеет запускать систему. Мне вот пришлось копаться в исходниках, когда lvm не хотел
дружить с dmraid, так что я точно знаю, что это баш. 

Причём тут исходники upstart'a? С чего вы взяли, что для успешного запуска линукса необходим монстр вроде upstart,
systemd или openrc? Любой скрипт сойдёт. Я читал, как энтузиасты сваяли init скрипт на common lisp, а потом сидели в нём
через удалённый отладчик, который REPL. Забавно, но не практично. Продвинутые init­системы — это вопрос удобства
конечного пользователя, а не суровой необходимости.

 andvgal  17 августа 2016 в 21:16   +4      

Думаю в статье не указано самое главное, а именно поддержка cgroup и limits в systemd из коробки, не говоря уже о namespaces. 

Теперь «родные» сервисы крайне легко разграничить так, чтобы они не мешали другим в рамках той же системы. Например,
действительно без войны ресурсов удаётся запускать несколько сервисов баз данных или JVM на одной системе без контейнеров
или виртуалок. 

Автоматически рестарт помог избавиться от костылей на daemontools или runit. 

P.S. Сам года два противился systemd пока не познал весь его дзен.

  prometheus_ru  17 августа 2016 в 22:39        ⬆ +1      

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

 zunkree  18 августа 2016 в 01:03        ⬆ 0   

Откройте для себя OpenRC, где так же есть поддержка cgroups и limits из коробки.

  AVX  17 августа 2016 в 21:22   0   

Вначале было просто: загрузчик — ОС — программы 
Потом так: загрузчик — ОС — система запуска — программы 
И если раньше было как бы понятно, что ОС в целом разрабатывает команда разработчиков конкретного дистрибутива, которая и
заботится о системе управления пакетами программ, запуском и прочими вещами; то теперь система запуска явно выделилась в
нечто отдельное, за которое вроде никто и не отвечает. Создатели systemd как бы не отвечают за unit файлы, а предоставляют
это разработчикам дистрибутивов и программ. Разработчики дистрибутивов при всём желании не смогут для кучи программ это
всё перепахать, а разработчики программ плевать хотели на то, как и кто их будет запускать, и уж тем более про какой­то
стандарт запуска­остановки­рестарта­(чего­угодно­ещё). 
Сколько не смотрел — во всех дистрибутивах такой бардак, мешанина из sysv, upstart и systemd. Для серверов, по большому
счёту, systemd не особо и надо, а вот для всяких мобильных устройств, типа ноутбуков и планшетов и смартфонов (и прочего
барахла) — будет сильно заметна разница — в одном случае загрузка за 3 секунды, в другом за 15с.

  prometheus_ru  17 августа 2016 в 22:40        ⬆ +2      

Поверьте, systemd и наблюдение за службами еще как надо на серверах. Потому что хочется быть уверенным, что если
служба вылетит с segmentation fault или еще как, будет кому подхватить упавшее знамя.

 grossws  17 августа 2016 в 22:49        ⬆ +1      

В rhel/centos 7 бардака не наблюдается. В 6 — было выше крыши, из­за соседства upstart и sysv.

 larrabee  18 августа 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
минут.


   Invariant  18 августа 2016 в 04:07        ⬆ 0   

но как же bash ­x /etc/init.d/service_which_does_not_want_to_start ???

  AVX  18 августа 2016 в 08:44        ⬆ 0   

Спасибо, 7 не смотрел, буду изучать. Или всё­таки надо ещё раз арч поизучать (очень уж их вики хороша, на все вопросы
можно найти ответ). Идеология самого системд мне нравится, но как её реализуют во многих дистрибутивах — ужас.
Надеюсь, что это просто переходный период, пока нужна совместимость со старым софтом (который всё ещё написан с
ориентацией на sysv). 

 kay  17 августа 2016 в 21:37   0   

Так и не понял на кого жалуется автор. На разработчиков systemd или на разработчиков ПО, которые пилят что­то вроде:

ExecStart=/etc/init.d/service start 
ExecStop=/etc/init.d/service stop

Если последнее, то возможно это даже не разработчики, а мантейнеры пакетов.

  prometheus_ru  17 августа 2016 в 22:42        ⬆ 0   

Тут виноваты и те, и другие. 

Разработчикам пофиг, они только SysV поддерживают. Мэйнтейнеры пакетов обычно кладут на необходимость создания unit­
файлов, ведь SysV же работает. 

Замкнутый круг.

  gold_user  17 августа 2016 в 22:40   0   

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

  prometheus_ru  17 августа 2016 в 22:41        ⬆ 0   

Я, увы, не профессионал в этой области, поскольку специализируюсь на Debian/Ubuntu. Не знаком с реализациями OpenRC
под них.

  gold_user  18 августа 2016 в 08:07 (комментарий был изменён)         ⬆ 0   

Увы и ах, но от статьи я ожидал большего. Далеко не полно раскрыта тема, даже про systemd. Для сравнения,
статья 2011 года
Даже с машинным переводом информативнее, чем ваша статья. 

Основная проблема OpenRC в Debian — это лицензия. Поэтому вряд ли OpenRC появится в Debian по дефолту. 
OpenRC имеет свою реализацию команд
service и start­stop­daemon
и работает поверх rc­скриптов. Как это реализовано и работает можно посмотреть на примере Calculate Linux.
Сценарии инициализации

И еще, что­то я не могу понять, что мне даст выигрыш во времени при старте (не более одной минуты) использую systemd?

  AVX  18 августа 2016 в 08:48        ⬆ 0   

что мне даст выигрыш во времени при старте

Например, включаете телефон, и он загружается 40 секунд… или — 5 секунд. Есть разница? Другой пример —
видеорегистратор — задержка включения в полминуты уже очень неудобна, гораздо лучше когда запустится
практически сразу. Для одноядерных процессоров разницы по времени может и не быть, но сейчас чуть ли не в часах 2
и более ядра пихают.

  prometheus_ru  18 августа 2016 в 10:33        ⬆ +1      

Вы простите, но я не писал статью с обзором про systemd, таких обзоров на Хабре тысячи. 

Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду
причин. О которых я в полушутливой форме рассказал.

 daan  17 августа 2016 в 22:40   –2      

Буду краток: ненавижу systemd. 
Запилить монстра который заставил изменить привычный уклад жизни админа — достойно порицания.


   prometheus_ru  17 августа 2016 в 22:43        ⬆ +1      

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

 crlam0  18 августа 2016 в 00:29        ⬆ 0   

> Поверьте, уклад жизни админа начал меняться еще с Upstart.  

Вы забыли уточнить: Debian/Ubuntu админа.

 grossws  18 августа 2016 в 00:33        ⬆ 0   

В rhel6 тоже был upstart, хотя большая часть софта жила на sysv init­скриптах.

 crlam0  18 августа 2016 в 00:51 (комментарий был изменён)         ⬆ 0   

Я отвечал @prometheus_ru, который чуть выше написал «Я, увы, не профессионал в этой области, поскольку
специализируюсь на Debian/Ubuntu».  

Но тем не менее: Вы только подтверждаете что с появлением Upstart жизнь админа не менялась, раз в RHEL6 его
появление не особо задело.

  prometheus_ru  18 августа 2016 в 00:52        ⬆ 0   

RHEL6 еще как задело. Потому что там наблюдалось примерно то, что сейчас в Ubuntu 16.04. RHEL7 тоже задело,
поскольку убежали на systemd.

 daan  18 августа 2016 в 12:35        ⬆ 0   

Upstart это эволюция SysV init scripts. 
Systemd — революция. 
Привычный уклад — это не застой, а стабильное совершенствование, планомерное движение к лучшему. 
Systemd предлагает новую философию, подход и заставляет тратить время на то, что до его прихода уже работало.

 celebrate  17 августа 2016 в 23:53   0   

В systemd есть волшебная опция PrivateTmp, которая, являясь в принципе полезной, может надолго продлить дебаг некоторых
приложений.

 Prototik  18 августа 2016 в 00:09        ⬆ 0   

На то она и «волшебная» :) В любом случае надо понимать, что там в юните и к чему приведёт.

  symbix  18 августа 2016 в 00:49 (комментарий был изменён)    +1      

То, что в ubuntu main, кстати, более­менее по upstart­феншую было. Почти все sysv­добро в основном было унаследовано от
мейнтенеров дебиана, о которых я, пожалуй, лучше не буду говорить ничего (а ведь и на шелле можно сделать хорошо — см.
openrc). И о том, как они внедрили systemd, тоже не будут говорить ничего. 

Хороший пример, как надо использовать systemd — Arch.

  prometheus_ru  18 августа 2016 в 00:51        ⬆ 0   

Соглашусь про Arch, там systemd в полной мере и крайне хорош. Увы, Arch как по мне не достает неких LTS­версий, ну уж
больно rolling release. 

А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить,
чтобы для всего более или менее важного запилить скрипты на systemd.

  symbix  18 августа 2016 в 00:59        ⬆ 0   

Что поделать, нет в жизни счастья. Был проект arch­server, но сдох толком не родившись.

  dion  18 августа 2016 в 01:26   –1      

Самое хреновое в systemd — если что­то не так, то разобраться просто нереально. У меня вот на ноуте из­за cryptsetup этот
systemd тупо висит в попытке перезагрузиться. Как это чинить — я просто ума не приложу… А обычный SysV рабоатет отлично.

 L1Ntu  18 августа 2016 в 10:30   0   

Очень люблю смотреть на вайн «Я уже 15 лет админ, но вот в systemd уже 3 года никак нимагу ничего понять» 
Так может, стоит потратить 15 минут своего времени чтобы сесть и разобраться с systemd?

 develop7  18 августа 2016 в 10:54        ⬆ 0   

 а вдруг за 15 минут разобраться не получится и придётся потратить 20?

 delvin­fil  18 августа 2016 в 10:30   0   

Да что же так все привязались к UPSTART? Ну без обнов в Gentoo работает прекрасно SYSV. В чем проблема то?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Интересные публикации 

Координационный центр отвечающий за доменные зоны .RU и.РФ готовят к
национализации   0

Как починить «сломанный» VPS сервер на Linux   2

Так сразу и не DASH: зачем мы начинаем майнить самый параноидальный альткоин   2

Сам себе дизайнер. Тестируем 7 онлайн­сервисов для создания визуального контента   0

Отчет о посещении конференции YouTube в Киеве или Почему видеоконтент стал частью
жизни   1