Comments 170
Тем, кому кажется, что systemd просто, рекомендую посмотреть на современное устройство ceph. Там темплейты systemd дёргают триггеры upstart, которые инстансируют другие темплейты systemd, которые в свою очередь дёргают другие триггеры udev, которые, в свою очередь, дёргают systemd.
отлаживать это — одно удовольствие.
отлаживать это — одно удовольствие.
В защиту SysV хочу сказать, что он предельно прост и понятен широчайшим слоям пользователей. Даже полные ламеры, вроде меня, способны в кратчайшие сроки, при помощи гугла, форумов и старших товарищей слепить удобоваримый скрипт запуска демона. Более того, достаточно прозрачен механизм работы: просто посмотрев содержимое каталога, можно понять что и когда будет запущено. И контрольный в голову: этот скрипт из желудей и веток будет беспроблемно работать годами. А если перестанет, то его в состоянии будет починить практически любой, кто немного знаком с линуксом.
В противовес же SysV, чтобы что-то настроить в systemd, нужно освоить мануал на 10 страниц, все эти юниты со своими конфигами и синтаксисом, этот systemctl с непонятными параметрами… я не админ, мне не нужна эта информация на каждый день (кстати, сдается мне что админам она тоже нужна далеко не каждый день), мне раз в пять лет надо настроить запуск демона и забыть про него. Средствами файловой системы это сделать много проще и понятнее.
Вот лично для меня systemd не несет никаких удобств. Быть может поэтому его и многие другие игнорируют?
В противовес же SysV, чтобы что-то настроить в systemd, нужно освоить мануал на 10 страниц, все эти юниты со своими конфигами и синтаксисом, этот systemctl с непонятными параметрами… я не админ, мне не нужна эта информация на каждый день (кстати, сдается мне что админам она тоже нужна далеко не каждый день), мне раз в пять лет надо настроить запуск демона и забыть про него. Средствами файловой системы это сделать много проще и понятнее.
Вот лично для меня systemd не несет никаких удобств. Быть может поэтому его и многие другие игнорируют?
Прочитайте внимательно. Бывает, что скрипты на SysV стартуют, однако приложение по какой-то причине вываливается на старте. Что делать? Я понимаю, запустить руками. Но без режима контроля и рестарта многие современные приложения тупо не работают нормально.
Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом.
А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.
Мануал на 10 страниц осваивать на надо. Не админу достаточно одну статью прочитать с базисом.
А вот про удобоваримый скрипт для запуска демона — гм, смотря что считать удобоваримостью.
Да я прочитал. Да, бывает. Правда, в моей практике приложения падали и при запуске скриптом и при запуске руками, так что все это достаточно просто диагностировалось. Видимо просто сложных случаев не было.
Удобоваримый — это тот который, несмотря на всю свою кривизну, выполняет возложенные на него функции.
Эх, вашими бы устами… я вот сейчас почитал вводную статью, посмотрел примеры в своей системе. Понял что я по прежнему не имею представления в каком порядке все это запускается… понял что если вот прямо сейчас я немного уловил логику конструирования всего этого, то год спустя мне всю процедуру (включая чтение вводной статьи) придется начинать сначала.
Вы в статье спрашивали почему все так держатся за SysV? Я ответил почему за него держусь я.
Удобоваримый — это тот который, несмотря на всю свою кривизну, выполняет возложенные на него функции.
Не админу достаточно одну статью прочитать с базисом.
Эх, вашими бы устами… я вот сейчас почитал вводную статью, посмотрел примеры в своей системе. Понял что я по прежнему не имею представления в каком порядке все это запускается… понял что если вот прямо сейчас я немного уловил логику конструирования всего этого, то год спустя мне всю процедуру (включая чтение вводной статьи) придется начинать сначала.
Вы в статье спрашивали почему все так держатся за SysV? Я ответил почему за него держусь я.
Понял что я по прежнему не имею представления в каком порядке все это запускается…А почему вы считаете что есть какой-то один порядок и почему вас это вообще волнует?
Вы когда Makefile пишите тоже пытаетесь вычислить в какой последовательности файлы будут компилироваться?
какой-то один порядок и почему вас это вообще волнует?
Почти в 100% случаев не волнует. Но я могу себе представить случай, когда надо запустить какой-нибудь условный торрент-клиент, который будет работать с файлами на смонтированных шарах. Мне кажется логичным, чтобы сначала запускался скрипт монтирования, а уже потом — приложение, которое с шарами будет работать. Параллельно их можно выполнить, но кто поручится за результат?
И для этого в systemd есть зависимости между unit'ами, чего фактически нет в runit, который всякие странные люди приводят как альтернативу systemd.
Указываете, для вашего условного rtorrent.service Requires=media-share.mount + After=media-share.mount и всё работает. При попытке запустить rtorrent.service будет монитроваться шара и основной юнит будет запускаться после, при попытке отмонтирования шары будет останавливаться сервис.
Я прям не знаю, вы все как будто придуриваетесь:) Перечитайте мой первый комментарий: я не админ и не хочу им быть. Я простой пользователь. И у меня, пользователя, пытаются отнять простой инструмент и дают взамен сложный. И эта замена мне, пользователю, никаких плюшек не сулит. Это как у среднестатистического водителя отнять 5-ступенчатую коробку передач и дать ему взамен 25-ступенчатую. Оно может и здорово и на всякой спецтехнике я встречал нечто подобное, но обычному водителю-то это нафига?
Если вы выступаете в роли простого пользователя, а не админа (пусть и локалхоста), то вы не будете писать инит-скрипты/юниты, а будете использовать готовое приложение (вероятно, с gui или tui). В случае, если вас что-то не устраивает, то (в этой роли) будете писать feature request'ы и излагать своё видение проблемы на форуме/в багтрекере etc.
Иначе вы принимаете роль админа, которая требует понимания своих действий и банального умения читать документацию. И ваша жалоба не несёт никакого смысла.
Предположим приложение упало, что сделает systemd?
Проанализирует ошибку с которой упало приложение и исправит или тупо перезапустит снова?
Проанализирует ошибку с которой упало приложение и исправит или тупо перезапустит снова?
Для начала, узнает, почему упало. Т.е. если его остановил админ, то перезапускать не надо.
Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось.
Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли его перезапускать. С systemd он будет перезапущен без Вас.
Если админ ничего не делал, а приложение ушло, то перезапустит. Приложение ведет лог, причем systemd помогает делать это в едином месте. Пусть админ потом разбирается, почему упало и что случилось.
Поверьте, эта логика важна для критичных сервисов. Допустим стоит у вас postfix, в котором нашлась ошибка критическая, которая позволяет повалить его злоумышленнику. Его повалили ночью. Сработал мониторинг, вы пошли его перезапускать. С systemd он будет перезапущен без Вас.
Предположим что это не postfix и что то случилось с данными на диске и сервис из за этого падает. А при старте он жрёт много процессорного времени и снова падает. В итоге из за systemd лежать весь сервер, да так гораздо лучше.
А для падучих сервисов ну можно расписать скрипт который висит в памяти и сам перезапускает упавший сервис. Что в своё время я и делал для одного игрового сервиса.
Я ничего против systemd не имею, но я им и не пользуюсь, однако усложнение системы старта когда не можешь найти, где, что и как стартует не радует.
А для падучих сервисов ну можно расписать скрипт который висит в памяти и сам перезапускает упавший сервис. Что в своё время я и делал для одного игрового сервиса.
Я ничего против systemd не имею, но я им и не пользуюсь, однако усложнение системы старта когда не можешь найти, где, что и как стартует не радует.
Нет, вы можете указать, сколько раз пытаться перезапускать. Дефолтных значений типа 5 хватает.
А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
>> А что делать, если перезапускающий скрипт вылетит? :) systemd есть init, если он вылетел, то у нас есть проблема поважнее.
Вот именно если вылетит мой скрипт то в целом жить можно а если systemd то да жизнь сложней.
>> Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны. И за много лет как я с этим познакомился ничего не поменялось. Всё как то по старому.
Я не знаю что должен был решить systemd, может по этому и не понимаю зачем он.
Вот именно если вылетит мой скрипт то в целом жить можно а если systemd то да жизнь сложней.
>> Вы совершенно правы, что произошло усложнение системы старта. Но не из-за systemd, а просто потому, что жизнь стала такой.
Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны. И за много лет как я с этим познакомился ничего не поменялось. Всё как то по старому.
Я не знаю что должен был решить systemd, может по этому и не понимаю зачем он.
Я же еще раз говорю, получается яицо в яице: мы пишем скрипт, который следит за скриптом, который следит за скриптом.
У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с ошибкой. И никак не перезапускалось. И жизнь — боль :)
У автора лично было несколько случаев, когда на старте системы /etc/init.d/service start отрабатывало с ошибкой. И никак не перезапускалось. И жизнь — боль :)
Очень жаль, что OpenRC практически нигде кроме Gentoo и производных не пытались использовать :( А ведь в ней реализована и работа с зависимостями, и параллельный запуск (на сколько помню, в тестовом режиме, но тем не менее), а главное весьма простые и логичные скрипты запуска. Даже контейнеры можно с ней запускать. Да, по сравнению с SystemD нет работы с cgroups, нет отслеживания запущенных процессов, но зато это и не такой комбайн, включающий в себя очень много того, что имхо к системе инициализации отношения или не имеет, или имеет, но очень отдаленное.
Я уже много лет сижу на OpenRC и он по прежнему при ребуте пускает мне нужные демоны.
Админу локалхоста наверное больше и не нужно.
А разве при написание «юнита» systemd админ не может указать, чтобы systemd его не перезапускал? Специально не искал, но как будто бы можно. Я только пару раз автоматизировал старт Java приложений под systemd и проблем там не увидел, в отличие от SysV. там есть практически все, просто нужно правильно это испоьзовать.
Админ ленив, чтобы читать мануалы как расписать ещё один скрипт для ещё одной системы старта, которая моложе чем аптайм его сервера.
Если админ хочет работать только с серврами, который были запущены до появления systemd, то почему его вообще волнует что происходит в современных дистрибутивах Linux?
Видимо программисты сами должны писать скрипты запуска для самописных приложений(что большинство и делает), а админы ленивые и консервативные. И не в их интересах отрываться от «важных» задач, чтобы идти в ногу со временем.
Linux используют не только админы. Он сейчас и в embeded распространён. И вот когда попадается железка на которой стоит systemd(свежие чуть ли не поголовно) и задача стоит вырезать всё лишнее, и сделать старт максимально быстрым. То тут приходится узнавать что это за хрень и как её есть. Ну или второй вариант init из busybox и пару простых скриптов. Чтобы не думать какого хрена всё таки запустился wpa-suplicant хотя ты точно его прибивал.
Если админ не хочется развиваться, идти в ногу со временем, и поглядывать на новые веяния — это его выбор. Но ничего удивительного, что это путь к профессиональному застою со всеми вытекающими последствиями.
В некоторые профессиях (например, бухгалтерское дело) без постоянного отслеживания изменений и нововведений вообще работать невозможно. Попробуйте в 2016 году вести бухучет по нормативам 2000 года…
В некоторые профессиях (например, бухгалтерское дело) без постоянного отслеживания изменений и нововведений вообще работать невозможно. Попробуйте в 2016 году вести бухучет по нормативам 2000 года…
И как мне простите, работать с этим бинарным логом, особенно если бинарное ,… забило мне /var/log под завязку и побилось? как мне присобачить к нему какойнить… да хотя бы fail2ban на ssh перебор? глаза бы мои этого journalg не видели, если честно.
А вот паралельный стар хорош и быстр. Но у меня, например поверднс должен стартовать после постгреса, а докер после поверднса. а потом нгинкс, на закуску. А в результате я хожу ручками и перестартовываю всю эту цепочку потому как при очередном апт-гет апдейт у нас половина моих кастомных конфигов юнитов обновилась на те что шли с пакетом
А вот паралельный стар хорош и быстр. Но у меня, например поверднс должен стартовать после постгреса, а докер после поверднса. а потом нгинкс, на закуску. А в результате я хожу ручками и перестартовываю всю эту цепочку потому как при очередном апт-гет апдейт у нас половина моих кастомных конфигов юнитов обновилась на те что шли с пакетом
Да, есть такая проблема, текущий формат журнала довольно хрупок. Но он хотя бы умеет сам свой размер на диске ограничивать, в отличии от.
Значит, вы что-то делаете не так. Админ свои самописные юниты должен класть в /etc/systemd/system чтобы они не затирались вендорскими. Но в большинстве случаев и этого не нужно, достаточно systemctl edit foo.service и дописать/перекрыть/дополнить только нужные куски. В т.к. и объяснить, что после чего должно стартовать на конретной машине, можно так. Почитайте документацию по systemd, это окупится.
Но в большинстве случаев и этого не нужно, достаточно systemctl edit foo.service и дописать/перекрыть/дополнить только нужные куски.
Edit есть не во всех широкоиспользуемых версиях systemd. Но он де-факто создаёт такой же drop-in, который рекомендуется создавать пользователю (типа /etc/systemd/system/nginx.service.d/override.conf).
Но он хотя бы умеет сам свой размер на диске ограничивать
Если файл лога быстро разростается — проблема НЕ в его разростании. а в том ПОЧЕМУ он стал разростаться, и это уже ТРИГГЕР даже в обычном заббиксе о проблеме. То, что он затрёт мне события часовой давности — это минус.
классический рсислог в этом случае проще, удобнее и приятнее — на одном из соседних проектов логи складываются в SQL, logstash и ещё в архив отдельный. а держать journald чтобы он отправлял данные в rsyslog, который разложит логи куда надо на этой же машине — я считаю оверхедом.
А в результате я хожу ручками и перестартовываю всю эту цепочку потому как при очередном апт-гет апдейт у нас половина моих кастомных конфигов юнитов обновилась на те что шли с пакетом
А вы их в /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.
Я так вообще извращался: писал скрипты старта-запуска jenkins'а (дефолтного с war-ом не поставляется), копипастил (ну не то, чтобы я разбираюсь в почти-rc-конфигах (по сути) sysD) файл сервиса (любого) в нужное мне место, а затем правил его, вписывая адреса нужных мне скриптов, а также правя название.
А мне наоборот systemd нравится своей простотой. Скрипты SysV очень монструозные, и раньше я всегда «таскал» их с гугла, пару раз приходилось писать свой сервис и это заняло тогда много времени, тогда как в systemd сервис пишется за несколько минут на коленке, достаточно скормить исполняему файлу параметры запуска и останова.
Нет. Юнит на systemd пишется в 4 строчки и не содержит в себе никакой магии. А вот ритуалы sysv-init (с подключением functions, использованием start-stop-daemon) — вот это реальная магия. Отладка же этой магии — то ещё развлечение.
Непривычно — да. Но это быстро проходит.
Непривычно — да. Но это быстро проходит.
все сделано для людей…
Всё, что я думаю о systemd в одной картинке — https://pbs.twimg.com/media/ChIcfpoXEAAPgFN.jpg
Вы привели отличный пример уробороса. Автор пытается рестартовать службу при помощи /etc/init.d/service, что по сути работать не должно.
Однако в системе кто-то об этом побеспокоился и сделал велосипед /etc/init.d/service -> systemd, но что-то пошло не так, поскольку надо смотреть, как написан .service-файл.
Однако в системе кто-то об этом побеспокоился и сделал велосипед /etc/init.d/service -> systemd, но что-то пошло не так, поскольку надо смотреть, как написан .service-файл.
> что по сути работать не должно.
Вообще отношения к делу не имеет.
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), чем тратить время на разбирательства.
Вообще отношения к делу не имеет.
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), чем тратить время на разбирательства.
systemctl cat rsync в студию, покажите. Для начала разберемся, как оно запускается. Но /etc/init.d/service с systemd надо забыть.
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
Сразу по косякам.
--daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все хорошо. Type= не указано, поэтому systemd считает, что это simple.
1. Я бы попробовал добавить Type=forking в секцию Service.
2. У rsync очень особое понимание того, как оно запущено. --daemon обозначает не просто fork, а еще пояснение, что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так:
[Service]
Type=simple
ExecStart=/usr/bin/rsync
--daemon — а зачем? Как только оно делает fork и отваливается потом, systemd не может гарантировать, что все хорошо. Type= не указано, поэтому systemd считает, что это simple.
1. Я бы попробовал добавить Type=forking в секцию Service.
2. У rsync очень особое понимание того, как оно запущено. --daemon обозначает не просто fork, а еще пояснение, что rsync запускается не из под inetd. Интереса ради я бы попробовал бы еще вот так:
[Service]
Type=simple
ExecStart=/usr/bin/rsync
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), хотя даже не должен пытаться.
Он, судя по всему, не пытается. Из документации следует, что если эта проверка фейлится, то 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.
А что пишет systemctl status rsync?
Ваш коммент ниже подтверждает, что все именно так, как в документации :)
Да все работает -> вопрос на 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]#
Да, можно сказать, что это костыль. Я спорить не буду )))
UFO just landed and posted this here
Это дефолтный unit из дебиана, я его не писал.
Если основные мейнтейнеры дебиана (а rsync — один из core-пакетов) ошибаются в этом инструменте, чего ждать от обычных людей, которые доки читают всегда по диагонали?
Если основные мейнтейнеры дебиана (а rsync — один из core-пакетов) ошибаются в этом инструменте, чего ждать от обычных людей, которые доки читают всегда по диагонали?
UFO just landed and posted this here
Если основные мейнтейнеры дебиана не справляются с написанием 7 строк конфига, то как можно от них ожидать, что они справятся с написанием скрипта на сотни строк? Хотя, на мой взгляд, с задачей они справились на отлично. rsync работает не только в серверном, но и в клиентском режиме. Зачем вам в логах лишняя ошибка при загрузке, если rsync установлен только для клиентского режима? Как только вы создатите конфиг демона, сервис начнет стартовать. Что может быть логичнее, не представляю.
домашний админ — на роутере hardened gentoo (без SE) на рабочей дизайнерской машине просто gentoo с open-rc — приложения запускаются, за сеть спокоен, да — нет гнома3 и прочей «графы», xfce устраивает… без systemd.
Есть такая штука — EPM
http://wiki.etersoft.ru/Epm
помимо управления пакетами, там есть команда serv, которая
обеспечивает управление сервисами вне зависимости от системы.
Возможно, это то, что вы искали.
http://wiki.etersoft.ru/Epm
помимо управления пакетами, там есть команда serv, которая
обеспечивает управление сервисами вне зависимости от системы.
Возможно, это то, что вы искали.
Интересно, спасибо!
Но вот смотрю я на 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» ))
Но вот смотрю я на 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» ))
Если называете очередным костылём, поделитесь, какие были ещё, я не видел.
> почему нельзя было написать для людей epm install
epm поддерживает все привычные варианты, для людей, имеющих опыт работы с любым ПМ. Это видно в выводе epm --help
Так, установить пакет можно командами epmi, epm -i, epm install.
Ситуацию с вхождением EPM в дистрибутивы исправим, если в этом видится смысл.
Про разные названия пакетов и сервисов вы правы. Но это просто ещё не доделанная часть. И, всё же, epm для людей в первую очередь, а во вторую для скриптов.
> те, кто обслуживают сервера, обычно сидят на одном каком-то дистре
Мне и моим скриптам приходится обслуживать несколько десятков дистрибутив, так что я понимаю этих людей.
> добавим еще парочки «солярок», и несколько FreeBSD разных версий
На всякий скажу, что epm работает и на Solaris, и на FreeBSD, и на OpenWRT, и немного на на MacOS и Android.
По сути важная проблема одна — названия. И тут я жду совета.
> почему нельзя было написать для людей epm install
epm поддерживает все привычные варианты, для людей, имеющих опыт работы с любым ПМ. Это видно в выводе epm --help
Так, установить пакет можно командами epmi, epm -i, epm install.
Ситуацию с вхождением EPM в дистрибутивы исправим, если в этом видится смысл.
Про разные названия пакетов и сервисов вы правы. Но это просто ещё не доделанная часть. И, всё же, epm для людей в первую очередь, а во вторую для скриптов.
> те, кто обслуживают сервера, обычно сидят на одном каком-то дистре
Мне и моим скриптам приходится обслуживать несколько десятков дистрибутив, так что я понимаю этих людей.
> добавим еще парочки «солярок», и несколько FreeBSD разных версий
На всякий скажу, что epm работает и на Solaris, и на FreeBSD, и на OpenWRT, и немного на на MacOS и Android.
По сути важная проблема одна — названия. И тут я жду совета.
Спасибо за ссылку. Увы, не уверен, поскольку я предпочитаю автоматизироваться через chef и использовать все-таки нативные инструменты.
По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что-то сделать. Я не вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно.
Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты накатить, разбирайся как».
Но за ссылку еще раз спасибо, интересно.
По сути, как гениально не пиши, но получится еще один бинарь /usr/sbin/service, который должен за меня что-то сделать. Я не вижу в этом особого смысла, поскольку предпочитаю общаться с systemd, например, самостоятельно.
Про установку пакетов еще хитрее. На сегодня не автоматизировать свою работу может только админ, у которого много свободного времени. У меня процентов на 70% прод работает из Chef, поэтому я и так уже говорю «Chef, мне тут пакеты накатить, разбирайся как».
Но за ссылку еще раз спасибо, интересно.
В итоге, несмотря на то, что Upstart царствовал в Ubuntu 5 лет на протяжении с 2009 до 2014 года, огромное количество софта так и не перешло на него!Этого не случилось, как минимум, потому что Linux это не только Ubuntu. Ну а когда все поняли что уже надо бы что-то сделать, systemd показался сообществу более перспективным.
А я говорю конкретно про Ubuntu. Upstart был там аж с 2006 на подтанцовках, а с 2009 уже во все поля. За пять лет ничего толком не изменилось, в 14.04 Apache так и стартует до сих пор из SysV.
Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.
Уже говорил тут, но повторю еще раз: денег Canonical должно было бы хватить не только запилить Upstart, но и потрудиться для него написать скрипты для программ. А этого сделано не было, SysV всех устраивал.
Из-за этого были прекрасные баги с, например, убийством mongodb, когда при ребуте их sysv'шные скрипты убивали всё через небольшое время (то ли 2 минуты, то ли 15 секунд между SIGTERM и SIGKILL) несмотря на timeout'ы в upstart-скриптах. Для меня это был один из факторов отказа от ubuntu server lts (тогда была 10.04) и ухода на centos.
Ай, я со времен того же 10.04 собираю почти важные пакеты (для разных серверных демонов там) самостоятельно.
Все эти дела в ubuntu прилетают из debian-а практически без изменений, а там такое… Нет, правда. Если у вас все работает и вас все устраивает, в deb-src просто не смотрите, никогда не смотрите. Не надо.
У centos (точнее, у RHEL) другая проблема — там штатно вообще ничего нет, а то, что есть, устарело еще до релиза. Понятно, что все решается подключением всяких epel-ов, но это уже другой дистрибутив получается.
Все эти дела в ubuntu прилетают из debian-а практически без изменений, а там такое… Нет, правда. Если у вас все работает и вас все устраивает, в deb-src просто не смотрите, никогда не смотрите. Не надо.
У centos (точнее, у RHEL) другая проблема — там штатно вообще ничего нет, а то, что есть, устарело еще до релиза. Понятно, что все решается подключением всяких epel-ов, но это уже другой дистрибутив получается.
По сути да, 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 — аналогично). Этот вариант несколько медленнее, чем держать сервер с необходимым окружением, но даёт всегда сборку в чистом окружении.
О, с докером идея годная, надо будет тоже так сделать себе в Ubuntu. Я пока обычным lxc-контейнером обхожусь, который восстанавливаю из копии, если невзначай загадил.
А на rpm и его спеки у меня почему-то аллергия. Объективно вроде все нормально, но как-то не радуют, как те поддельные воздушные шарики. Наверное, моральная травма от старых редхатов без yum: как-то лет 12 назад пришлось самому рекурсивно выкачивать rpm-ки по зависимостям и у меня кончился стек — забыл, что хотел поставить. :)
А на rpm и его спеки у меня почему-то аллергия. Объективно вроде все нормально, но как-то не радуют, как те поддельные воздушные шарики. Наверное, моральная травма от старых редхатов без yum: как-то лет 12 назад пришлось самому рекурсивно выкачивать rpm-ки по зависимостям и у меня кончился стек — забыл, что хотел поставить. :)
> Во-вторых, SysV было глубоко плевать на интимную жизнь программ. Он их запускал на старте, но если у тебя что-то не получалось, то это был их личные проблемы. Отлаживать такие вещи, кстати, практически невозможно. Segmentation fault? Настоящие мужчины пишут программы, которые запускаются с первого раза и не сегфолтят, слабак.
А почему init должен заботиться о личной жизни программ? Для этого существуют специализированные бэби-ситтеры: олдовый daemon tools или хипстерский monit. Принцип unix-way: делай своё дело хорошо, и дай остальным возможность делать своё дело. Но даже если вы страдаете от NIH синдрома, не обязательно встраивать свой daemon tools в init, его можно выпустить как отдельное приложение.
Кстати, в обзоре разных init программ, вы забыли о том, что init — это по сути простой скрипт, некоторые пишут полностью кастомный скрипт запуска системы на каком-нибудь баше или ещё лучше — на си. Если важна скорость запуска, а система давно уже не меняется с точки зрения добавления/удаления демонов, то вполне себе выбор.
> Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.
Такое впечатление, что вы не подозреваете о существовании альтернативных точек зрения. Например, о том, что софт не всегда запускается инитом. Ну там можно запускать отладочную версию. Или пользователь может запускать демон в своих собственных, а не системных, целях. Опять же демону лучше знать, как он инициализируется, ресетит полномочия, и почему ему удобнее демонизироваться.
Кстати о systemd, авторы не только переизобрели daemon tools, но ещё и inetd до кучи.
А почему init должен заботиться о личной жизни программ? Для этого существуют специализированные бэби-ситтеры: олдовый daemon tools или хипстерский monit. Принцип unix-way: делай своё дело хорошо, и дай остальным возможность делать своё дело. Но даже если вы страдаете от NIH синдрома, не обязательно встраивать свой daemon tools в init, его можно выпустить как отдельное приложение.
Кстати, в обзоре разных init программ, вы забыли о том, что init — это по сути простой скрипт, некоторые пишут полностью кастомный скрипт запуска системы на каком-нибудь баше или ещё лучше — на си. Если важна скорость запуска, а система давно уже не меняется с точки зрения добавления/удаления демонов, то вполне себе выбор.
> Однако как быть с сервисами, которым нужен fork? Ну для начала их надо спросить, зачем им это? Ведь в целом, fork применялся в основном для того, чтобы детачнуться от стартовавшего их процесса, но в случае с Upstart это делать незачем. Если у нас умер init, то у нас есть чуть больше проблем, чем неработающий postfix.
Такое впечатление, что вы не подозреваете о существовании альтернативных точек зрения. Например, о том, что софт не всегда запускается инитом. Ну там можно запускать отладочную версию. Или пользователь может запускать демон в своих собственных, а не системных, целях. Опять же демону лучше знать, как он инициализируется, ресетит полномочия, и почему ему удобнее демонизироваться.
Кстати о systemd, авторы не только переизобрели daemon tools, но ещё и inetd до кучи.
А почему init должен заботиться о личной жизни программ?Потому что больше некому? UNIX, видите ли, так устроен, что по-хорошему это может сделать только init. И, что самое итересное, когда-то давным-давно SysV init именно это и делал. Там, конечно, не без подводных камней было, но… по первоначальной задумке SysV init должен был это делать! Однако схема оказалась недостаточно гибкой и вместо того, чтобы довести её «до ума» она была обвешали невероятным количеством костылей.
Принцип unix-way: делай своё дело хорошо, и дай остальным возможность делать своё дело.Золотые слова! Проблема в том, что SysV init делает своё дело плохо!
Кстати о systemd, авторы не только переизобрели daemon tools, но ещё и inetd до кучи.А что в этом плохого? Обе эти программы существуют потому, что SysV init не справляется со взятыми на себя обязанностями. systemd — справляется, в нём в PID1 вернули то, что там всегда должно было быть! Так что костыли — можно выбросить за ненадобностью.
> Золотые слова! Проблема в том, что SysV init делает своё дело плохо!
А что она делает плохо? Программы запускаются? Запускаются. Ну по крайней мере на нашей стороне пуля вылетела нормально. С чего вы взяли, что ответственностью init является какой-то там системный мониторинг? Init — pid 1, он должен быть простым как автомат калашникова. Со всем остальным могут справиться pid > 1 (их если что и перезапустить не жалко). Я, кстати, втречал системный софт, который имеет встроенный бэби-ситтер, зачем им тогда ещё один на стороне инита нужен?
> systemd — справляется
systemd — это Nero (который болванки записывает) мира линукс. Безумный комбайнер, который умеет всё. Чуть ли не дистрибутив одной программой. Никто не спорит, что можно отлить всё в монолите, но зачем? Какова практическая ценность?
А что она делает плохо? Программы запускаются? Запускаются. Ну по крайней мере на нашей стороне пуля вылетела нормально. С чего вы взяли, что ответственностью init является какой-то там системный мониторинг? Init — pid 1, он должен быть простым как автомат калашникова. Со всем остальным могут справиться pid > 1 (их если что и перезапустить не жалко). Я, кстати, втречал системный софт, который имеет встроенный бэби-ситтер, зачем им тогда ещё один на стороне инита нужен?
> systemd — справляется
systemd — это Nero (который болванки записывает) мира линукс. Безумный комбайнер, который умеет всё. Чуть ли не дистрибутив одной программой. Никто не спорит, что можно отлить всё в монолите, но зачем? Какова практическая ценность?
Видите ли, логика простая. Один бэби-ситтер для всех лучше, чем каждый софт со своим бэби-ситтером, это раз. Далее, не все бэби-ситтеры одинаково хороши, это два. Разработчик должен писать софт, а не бэби-ситтеров, это три.
systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
systemd можно собрать мизерным, если выключить то, что не нужно. Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
> Один бэби-ситтер для всех лучше, чем каждый софт со своим бэби-ситтером, это раз.
Не факт. Единая точка отказа. Вон разработчики хрома пришли к тому, что на каждую вкладку надо запускать свой процесс. А я так уже давно делал на fluxbox, там можно любые приложения объединять во вкладки. В том числе uzbl (ныне покойный). Та же самая джава запускает по виртуальной машине на каждый процесс (у них такая самодиагностика, что помощнее бэби-ситтера будет). Так что чем плохо иметь несколько инстансов бэби-ситтера — не ясно.
> Далее, не все бэби-ситтеры одинаково хороши, это два
Если вас как разработчиков системы это волнует — напишите свой. Только не надо его встраивать в init, пусть будет независимой системой.
> Разработчик должен писать софт, а не бэби-ситтеров, это три.
Так есть же готовые. Потом, если у софта требования по надёжности работы в много девяток, то кастомный бэби-ситтер заточенный конкретно под этот софт — естественное решение.
> Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
Вопрос модульности не в дроблении, а во взаимозаменяемости. Есть хоть один компонент, который можно заменить на сторонний? Не теоретически, а на практике, так чтобы этот сторонний компонент существовал. Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.
Не факт. Единая точка отказа. Вон разработчики хрома пришли к тому, что на каждую вкладку надо запускать свой процесс. А я так уже давно делал на fluxbox, там можно любые приложения объединять во вкладки. В том числе uzbl (ныне покойный). Та же самая джава запускает по виртуальной машине на каждый процесс (у них такая самодиагностика, что помощнее бэби-ситтера будет). Так что чем плохо иметь несколько инстансов бэби-ситтера — не ясно.
> Далее, не все бэби-ситтеры одинаково хороши, это два
Если вас как разработчиков системы это волнует — напишите свой. Только не надо его встраивать в init, пусть будет независимой системой.
> Разработчик должен писать софт, а не бэби-ситтеров, это три.
Так есть же готовые. Потом, если у софта требования по надёжности работы в много девяток, то кастомный бэби-ситтер заточенный конкретно под этот софт — естественное решение.
> Кроме того, монолитность его сильно преувеличена, это набор мелких инструментов, которые взаимодействуют между собой.
Вопрос модульности не в дроблении, а во взаимозаменяемости. Есть хоть один компонент, который можно заменить на сторонний? Не теоретически, а на практике, так чтобы этот сторонний компонент существовал. Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.
Для модульной системы необходимо чётко очерченные открытые интерфейсы. Если они меняются каждый релиз, то система, пусть даже разбитая на несколько файлов, останется монолитной.
systemd состоит из разных бинарей. Никто не мешает Вам написать свой. Просто ныть о модульности любят, обычно, те, кто ничего писать и не собирался, а просто повторяет «монолитно это плохо», как мантру.
И про единую точку отказа, простите, забыл сразу.
init — всегда единая точка отказа. Коряво собранный initramfs — единая точка отказа. Корявый модуль ядра — единая точка отказа.
Если проблемы у init, то все остальное уже неважно. И эта логика в systemd хороша.
init — всегда единая точка отказа. Коряво собранный initramfs — единая точка отказа. Корявый модуль ядра — единая точка отказа.
Если проблемы у init, то все остальное уже неважно. И эта логика в systemd хороша.
inetd вообще на сегодняшний день не нужен никому, придуман был от бедности, поскольку latency была большой.
Я ни разу не забывал, что init — это простой скрипт, ну и что? Это как-то уменьшает его недостатки?
Ну и про альтернативные точки зрения. Для отладки можно (и нужно) запускать демон самому с нужной командной строкой. В чем проблема?
Я ни разу не забывал, что init — это простой скрипт, ну и что? Это как-то уменьшает его недостатки?
Ну и про альтернативные точки зрения. Для отладки можно (и нужно) запускать демон самому с нужной командной строкой. В чем проблема?
init — это по сути простой скрипт
Ага, написанный на Си. Вы хоть раз в его исходники заглядывали? Или исходники upstart'а?
Автор комментария, думаю, говорил об init, который из initramfs.
У вас на Си, у меня — на баше. Init — это что ядру будет передано как init, ядро честно исполнит любой скрипт. Подразумевается, что этот скрипт умеет запускать систему. Мне вот пришлось копаться в исходниках, когда lvm не хотел дружить с dmraid, так что я точно знаю, что это баш.
Причём тут исходники upstart'a? С чего вы взяли, что для успешного запуска линукса необходим монстр вроде upstart, systemd или openrc? Любой скрипт сойдёт. Я читал, как энтузиасты сваяли init скрипт на common lisp, а потом сидели в нём через удалённый отладчик, который REPL. Забавно, но не практично. Продвинутые init-системы — это вопрос удобства конечного пользователя, а не суровой необходимости.
Причём тут исходники upstart'a? С чего вы взяли, что для успешного запуска линукса необходим монстр вроде upstart, systemd или openrc? Любой скрипт сойдёт. Я читал, как энтузиасты сваяли init скрипт на common lisp, а потом сидели в нём через удалённый отладчик, который REPL. Забавно, но не практично. Продвинутые init-системы — это вопрос удобства конечного пользователя, а не суровой необходимости.
Думаю в статье не указано самое главное, а именно поддержка cgroup и limits в systemd из коробки, не говоря уже о namespaces.
Теперь «родные» сервисы крайне легко разграничить так, чтобы они не мешали другим в рамках той же системы. Например, действительно без войны ресурсов удаётся запускать несколько сервисов баз данных или JVM на одной системе без контейнеров или виртуалок.
Автоматически рестарт помог избавиться от костылей на daemontools или runit.
P.S. Сам года два противился systemd пока не познал весь его дзен.
Теперь «родные» сервисы крайне легко разграничить так, чтобы они не мешали другим в рамках той же системы. Например, действительно без войны ресурсов удаётся запускать несколько сервисов баз данных или JVM на одной системе без контейнеров или виртуалок.
Автоматически рестарт помог избавиться от костылей на daemontools или runit.
P.S. Сам года два противился systemd пока не познал весь его дзен.
Вначале было просто: загрузчик — ОС — программы
Потом так: загрузчик — ОС — система запуска — программы
И если раньше было как бы понятно, что ОС в целом разрабатывает команда разработчиков конкретного дистрибутива, которая и заботится о системе управления пакетами программ, запуском и прочими вещами; то теперь система запуска явно выделилась в нечто отдельное, за которое вроде никто и не отвечает. Создатели systemd как бы не отвечают за unit файлы, а предоставляют это разработчикам дистрибутивов и программ. Разработчики дистрибутивов при всём желании не смогут для кучи программ это всё перепахать, а разработчики программ плевать хотели на то, как и кто их будет запускать, и уж тем более про какой-то стандарт запуска-остановки-рестарта-(чего-угодно-ещё).
Сколько не смотрел — во всех дистрибутивах такой бардак, мешанина из sysv, upstart и systemd. Для серверов, по большому счёту, systemd не особо и надо, а вот для всяких мобильных устройств, типа ноутбуков и планшетов и смартфонов (и прочего барахла) — будет сильно заметна разница — в одном случае загрузка за 3 секунды, в другом за 15с.
Потом так: загрузчик — ОС — система запуска — программы
И если раньше было как бы понятно, что ОС в целом разрабатывает команда разработчиков конкретного дистрибутива, которая и заботится о системе управления пакетами программ, запуском и прочими вещами; то теперь система запуска явно выделилась в нечто отдельное, за которое вроде никто и не отвечает. Создатели systemd как бы не отвечают за unit файлы, а предоставляют это разработчикам дистрибутивов и программ. Разработчики дистрибутивов при всём желании не смогут для кучи программ это всё перепахать, а разработчики программ плевать хотели на то, как и кто их будет запускать, и уж тем более про какой-то стандарт запуска-остановки-рестарта-(чего-угодно-ещё).
Сколько не смотрел — во всех дистрибутивах такой бардак, мешанина из sysv, upstart и systemd. Для серверов, по большому счёту, systemd не особо и надо, а вот для всяких мобильных устройств, типа ноутбуков и планшетов и смартфонов (и прочего барахла) — будет сильно заметна разница — в одном случае загрузка за 3 секунды, в другом за 15с.
Поверьте, systemd и наблюдение за службами еще как надо на серверах. Потому что хочется быть уверенным, что если служба вылетит с segmentation fault или еще как, будет кому подхватить упавшее знамя.
В rhel/centos 7 бардака не наблюдается. В 6 — было выше крыши, из-за соседства upstart и sysv.
В CentOS 7 никакого бардака
Системных всего 2 скрипта, остальное зависит от мейнтейнеров пакета. На арче вообще никаких инит скриптов нет, мейнтейнеры справляются и пишут юниты для всего софта. Системд убрал много боли. Теперь, что бы понять как запускается демон можно просмотреть 5-15 строк кода, весто инит скрипта на две сотни строк, поправить или написать свой юнит дело 5 минут.
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 минут.
но как же bash -x /etc/init.d/service_which_does_not_want_to_start ???
Спасибо, 7 не смотрел, буду изучать. Или всё-таки надо ещё раз арч поизучать (очень уж их вики хороша, на все вопросы можно найти ответ). Идеология самого системд мне нравится, но как её реализуют во многих дистрибутивах — ужас. Надеюсь, что это просто переходный период, пока нужна совместимость со старым софтом (который всё ещё написан с ориентацией на sysv).
Как показывает практика (rhel/centos 7 и arch, плюс куча своего софта с переходом upstart -> systemd), софт почти всегда без проблем оборачивается в unit'ы без каких-либо сложностей. Причём в fedora/rhel мейнтейнеры осилили написать unit-файлы для подавляющей части софта в репозиториях, и мне абсолютно непонятно почему мейтейнеры debian'а не смогли использовать эти юнит-файлы с минимальными изменениями (типа использования /etc/default/ вместо /etc/sysconfig/ и подобной мелочёвки).
При этом написать корректный юнит проще, чем корректный init-скрипт, особенно если init-скрипт должен поддерживать несколько дистрибутивов.
В rhel/centos так себе, grep ExecStartPre находит много веселья. Вот в arch — почти ничего.
А в дебиане, мне кажется, мейнтенеры таким образом протестуют против навязанного им systemd, другого объяснения у меня нет :)
А в дебиане, мне кажется, мейнтенеры таким образом протестуют против навязанного им systemd, другого объяснения у меня нет :)
Золотые слова про протест :)
А что страшного вы нашли в ExecStartPre? Погрепал на паре своих серваков и ничего пугающего не обнаружил: проверка конфигов, создание маркерных файлов, создание необходимых директорий + chown + chmod, всякие docker create (ибо часть софта у меня в контейнерах и в ExecStartPre контейнер создаётся, в ExecStart делается docker start -a ..., а в ExecStopPost делает docker rm -f ...).
Debian пока еще поддерживает более одного типа init'а. Хотя systemd поумолчанию.
Если писать скрипты для каждого инита, это будет слишком много. Видимо поэтому маинтейнеры выбирают те скрипты, которые везде будут работать.
Если писать скрипты для каждого инита, это будет слишком много. Видимо поэтому маинтейнеры выбирают те скрипты, которые везде будут работать.
Так и не понял на кого жалуется автор. На разработчиков systemd или на разработчиков ПО, которые пилят что-то вроде:
ExecStart=/etc/init.d/service start
ExecStop=/etc/init.d/service stopЕсли последнее, то возможно это даже не разработчики, а мантейнеры пакетов.
OpenRC не хватает в этом списке. Как не крути, а он доступен, разрабатывается и списывать его со счетов не вижу повода. Если у вас иное мнение — не против выслушать его.
Я, увы, не профессионал в этой области, поскольку специализируюсь на Debian/Ubuntu. Не знаком с реализациями OpenRC под них.
Увы и ах, но от статьи я ожидал большего. Далеко не полно раскрыта тема, даже про systemd. Для сравнения,
Основная проблема OpenRC в Debian — это лицензия. Поэтому вряд ли OpenRC появится в Debian по дефолту.
OpenRC имеет свою реализацию команд
И еще, что-то я не могу понять, что мне даст выигрыш во времени при старте (не более одной минуты) использую systemd?
статья 2011 года
Даже с машинным переводом информативнее, чем ваша статья.https://www.ibm.com/developerworks/community/blogs/752a690f-8e93-4948-b7a3-c060117e8665/entry/comparativo_upstart_sysvinit_systemd_openrc?lang=ru
Основная проблема OpenRC в Debian — это лицензия. Поэтому вряд ли OpenRC появится в Debian по дефолту.
OpenRC имеет свою реализацию команд
service и start-stop-daemon
и работает поверх rc-скриптов. Как это реализовано и работает можно посмотреть на примере Calculate Linux. http://www.calculate-linux.ru/main/ru/openrc_manuals
Сценарии инициализации
http://www.calculate-linux.ru/main/ru/initscripts
И еще, что-то я не могу понять, что мне даст выигрыш во времени при старте (не более одной минуты) использую systemd?
что мне даст выигрыш во времени при старте
Например, включаете телефон, и он загружается 40 секунд… или — 5 секунд. Есть разница? Другой пример — видеорегистратор — задержка включения в полминуты уже очень неудобна, гораздо лучше когда запустится практически сразу. Для одноядерных процессоров разницы по времени может и не быть, но сейчас чуть ли не в часах 2 и более ядра пихают.
Вы простите, но я не писал статью с обзором про systemd, таких обзоров на Хабре тысячи.
Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду причин. О которых я в полушутливой форме рассказал.
Мне хотелось пояснить, что в королевстве Debian/Ubuntu плохо с системой инициализации. Плохо по целому ряду причин. О которых я в полушутливой форме рассказал.
Буду краток: ненавижу systemd.
Запилить монстра который заставил изменить привычный уклад жизни админа — достойно порицания.
Запилить монстра который заставил изменить привычный уклад жизни админа — достойно порицания.
Поверьте, уклад жизни админа начал меняться еще с Upstart. Потом стал меняться, когда стало понятно, что Debian тоже перейдет на systemd. Возможно, изменится еще раз, но пока systemd обладает всеми шансами на статус нового SysV. Поэтому автору крайне хочется, чтобы systemd стал стандартом у разработчиков софта.
> Поверьте, уклад жизни админа начал меняться еще с Upstart.
Вы забыли уточнить: Debian/Ubuntu админа.
Вы забыли уточнить: Debian/Ubuntu админа.
В rhel6 тоже был upstart, хотя большая часть софта жила на sysv init-скриптах.
Я отвечал prometheus_ru, который чуть выше написал «Я, увы, не профессионал в этой области, поскольку специализируюсь на Debian/Ubuntu».
Но тем не менее: Вы только подтверждаете что с появлением Upstart жизнь админа не менялась, раз в RHEL6 его появление не особо задело.
Но тем не менее: Вы только подтверждаете что с появлением Upstart жизнь админа не менялась, раз в RHEL6 его появление не особо задело.
Upstart это эволюция SysV init scripts.
Systemd — революция.
Привычный уклад — это не застой, а стабильное совершенствование, планомерное движение к лучшему.
Systemd предлагает новую философию, подход и заставляет тратить время на то, что до его прихода уже работало.
Systemd — революция.
Привычный уклад — это не застой, а стабильное совершенствование, планомерное движение к лучшему.
Systemd предлагает новую философию, подход и заставляет тратить время на то, что до его прихода уже работало.
В systemd есть волшебная опция PrivateTmp, которая, являясь в принципе полезной, может надолго продлить дебаг некоторых приложений.
То, что в ubuntu main, кстати, более-менее по upstart-феншую было. Почти все sysv-добро в основном было унаследовано от мейнтенеров дебиана, о которых я, пожалуй, лучше не буду говорить ничего (а ведь и на шелле можно сделать хорошо — см. openrc). И о том, как они внедрили systemd, тоже не будут говорить ничего.
Хороший пример, как надо использовать systemd — Arch.
Хороший пример, как надо использовать systemd — Arch.
Соглашусь про Arch, там systemd в полной мере и крайне хорош. Увы, Arch как по мне не достает неких LTS-версий, ну уж больно rolling release.
А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить, чтобы для всего более или менее важного запилить скрипты на systemd.
А про мейнтейнеров дебиана — я здесь могу только удивляться, поскольку по идее денег Canonical должно было бы хватить, чтобы для всего более или менее важного запилить скрипты на systemd.
Самое хреновое в systemd — если что-то не так, то разобраться просто нереально. У меня вот на ноуте из-за cryptsetup этот systemd тупо висит в попытке перезагрузиться. Как это чинить — я просто ума не приложу… А обычный SysV рабоатет отлично.
Очень люблю смотреть на вайн «Я уже 15 лет админ, но вот в systemd уже 3 года никак нимагу ничего понять»
Так может, стоит потратить 15 минут своего времени чтобы сесть и разобраться с systemd?
Так может, стоит потратить 15 минут своего времени чтобы сесть и разобраться с systemd?
Да что же так все привязались к UPSTART? Ну без обнов в Gentoo работает прекрасно SYSV. В чем проблема то?
Ужос просто. Как же мы жили без systemd? Я вот прекрасно жил — все у меня работало и продолжает работать годами. Пока есть возможность выбора системы инициализации. И гентушники вон живут и BSD. А вот пользователи «попсовых» linux как ничего не учили так ничему и не научатся хоть какой инит им поставь. А все потому что не хотят изучать как это работает внутри. Мои личные претензии к systemd:
1. Прямое нарушение unix-way:
— сложная система по определению не может выполнять хорошо все свои функции.
— стремится заменить собой другие демоны и системы, которые и так прекрасно работали и не имели отшения к init вобще(udev, syslog, ntp, настройки сети, даже патчи в ядро)
2. Внедрение этого «комбайна» делает невозможным существование остальных систем инициализации в принципе. Всем кому он по каким-то причинам не нравится приходится уже внедрять не поддержку альтернативного init, а создавать целые форки дистрибутивов или приписывать костыли-эмуляторы, что ведет к дальнейшей фрагментации мира linux.
1. Прямое нарушение unix-way:
— сложная система по определению не может выполнять хорошо все свои функции.
— стремится заменить собой другие демоны и системы, которые и так прекрасно работали и не имели отшения к init вобще(udev, syslog, ntp, настройки сети, даже патчи в ядро)
2. Внедрение этого «комбайна» делает невозможным существование остальных систем инициализации в принципе. Всем кому он по каким-то причинам не нравится приходится уже внедрять не поддержку альтернативного init, а создавать целые форки дистрибутивов или приписывать костыли-эмуляторы, что ведет к дальнейшей фрагментации мира linux.
Звучит примерно так:
Мои предки тысячелетиями катали квадратным колесом, и продолжают катать!
А вы мне тут рассказываете, что накруглом попсовом колесе — лучше
ПС.
unix тоже сложная система как такова, почему она может выполнять все свои функции хорошо?
Мои предки тысячелетиями катали квадратным колесом, и продолжают катать!
А вы мне тут рассказываете, что на
ПС.
unix тоже сложная система как такова, почему она может выполнять все свои функции хорошо?
Завуалированное обвинение в ретроградстве не является доказательством превосходства systemd.
Равно как и обращение к обобщению «unix», в контексте сложности систем.
Равно как и обращение к обобщению «unix», в контексте сложности систем.
хочу услышать конкретику, а не плачь аля
«Как же мы раньше жили» или
«да вы не понимаете, вот раньше, раааньше все было тааак хорошо без systemd» или
«systemd не может быть хорошая, потому что она сложная(другая)»
Вот привели тут ntp в пример, говорят что плохо. Ну ок
Что здесь кардинально трагического случилось?
Ах да, вот что: теперь не нужно поднимать ntp демон, просто для того чтобы синхронизировать свое время
Но все орут. Какжетаг, systemd теперь и временем управляет?
«Как же мы раньше жили» или
«да вы не понимаете, вот раньше, раааньше все было тааак хорошо без systemd» или
«systemd не может быть хорошая, потому что она сложная(другая)»
Вот привели тут ntp в пример, говорят что плохо. Ну ок
/usr/bin/timedatectl set-timezone Europe/Moscow
/usr/bin/timedatectl set-ntp true
/usr/bin/timedatectl status
Что здесь кардинально трагического случилось?
Ах да, вот что: теперь не нужно поднимать ntp демон, просто для того чтобы синхронизировать свое время
Но все орут. Какжетаг, systemd теперь и временем управляет?
/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?
sudo ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
Это уже в systemd-мире. До этого извращались кто во что горазд
Да ладно. А я эту команду даже в LFS встречал и в FreeBSD. А там systemd нет. Вон оно как оказывается…
В lfs есть вариант с systemd.
Но я говорил про то, что раньше это было дистрозависимо: где-то надо было сделать симлинк, где-то написать TZ= Europe/Moscow, где-то TimeZone=, где-то TIMEZONE=.
В одних дистрибутивах нужно было дополнительно настраивать restrict в /etc/ntpd.conf, в других — оно уже было в конфиге по умолчанию и т. п.
Итак, Gentoo, Debian, Ubuntu, Freebsd сколько себя помню всегда зона назначалась через симлинк в любых системах инициализации. Я почти уверен что это работает во всех дистрибутивах linux. То что вы где-то это вписываете в конфиг не значит что симлинк не работает. Unix-way же. Просто какая-то программа парсит конфиг и создает симлинк только и всего. Например в дебиане можно просто создать симлинк, а можно вызвать
dpkg-reconfigure tzdata сути это не меняет.
Раз уж мы заговорили про restrict приведите пример как он реализован в systemd. Я не про включить/выключить, а про скажем ограничить подсети.
dpkg-reconfigure tzdata сути это не меняет.
Раз уж мы заговорили про restrict приведите пример как он реализован в systemd. Я не про включить/выключить, а про скажем ограничить подсети.
Видимо, всякие вещи типа tzconfig/tzselect/timeconfig и подобные были просто tui-обёртками над ln -sf. Вполне допускаю такую возможность. Естественно, с тех пор, как glibc научилась использовать /etc/localtime. В начале 2000х это было не так, вне мира glibc это может быть не так и поныне.
Раз уж мы заговорили про restrict приведите пример как он реализован в systemd. Я не про включить/выключить, а про скажем ограничить подсети.
В systemd используется systemd-timesyncd, который является SNTP-клиентом и restrict — это не про него. Эту тему я поднял, т. к. зоопарк настроек ntpd по умолчанию и явная его избыточность для синхронизации времени привёл к массовому использованию ntp amplification атак.
Сравните разницу между
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 после которой тебе вообще ниочем не стоит беспокоиться
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 после которой тебе вообще ниочем не стоит беспокоиться
Ах ты ж. Конфиг ntp такой сложный — целых 20 строк. Установка ntp в одну команду — это конечно большая сложность. И запоминать нужно.
Хотя… стойте мне ведь тоже нужно запоминать команды и для systemd. А может и нет. Мануалы текстовые устарели. Даешь systemd-mand с переводом всех мануалов в бинарный формат и поддержкой тегов.
Хотя… стойте мне ведь тоже нужно запоминать команды и для systemd. А может и нет. Мануалы текстовые устарели. Даешь systemd-mand с переводом всех мануалов в бинарный формат и поддержкой тегов.
GNU 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 как стабильность и предсказуемость работы, гибкость и независимость от крупного бизнеса сводятся на нет.
Вот например 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 как стабильность и предсказуемость работы, гибкость и независимость от крупного бизнеса сводятся на нет.
Золотые слова! За что только заминусовали тебя? Ни одного возражения по существу, но минус, потому что твои слова противоречат их тупизне.
Вам действительно нужны «возражения по сути» к этой чуши? Ладно, потрачу 15 минут. Начнём с центрального утверждения:
Да что ж, это, чёрт побери, за unix-way такой, которому ни один Unix не следует? То есть вообще ни один?
А вот такой:
То есть «великий и священный» Unix-way, оказывается, не используется никем вообще, он существует только в больном воображении автора комментария. Удивительно ли, что никто эту чушь комментировать не хочет?
P.S. А unix-way между тем, вполне себе существует. Вот только разделение исходников хотя и позволяет правильно исполнять первую часть (пишите программы, которые делают что-то одно и делают это хорошо), но резко усложняют вторую (пишите программы, которые бы работали вместе). Потому-то все хорошо работающие программы (в том числе и systemd) используют один репозиторий из которого собираются много мелких программ. А вот с третьей (Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс) — тут да, тут systemd немного «отходит от темы», но вот как раз она — наиболее спорна, так как практика показала, что универсальность текстовых потоков, увы, не компенсирует их ненадёжности (сколько багов было посажено в скриптах, пытающихся разобрать логи из-за того что это невозможно сделать надёжно — ни в сказке сказать, ни пером описать).
Если я уберу одну какую-то часть системы или заменю её на другую то это практически не отразится на работоспособности остальных (функционально не связанных) компонентов.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 немного «отходит от темы», но вот как раз она — наиболее спорна, так как практика показала, что универсальность текстовых потоков, увы, не компенсирует их ненадёжности (сколько багов было посажено в скриптах, пытающихся разобрать логи из-за того что это невозможно сделать надёжно — ни в сказке сказать, ни пером описать).
Так откуда у нас в системе tar? Из пакета GNU tar, наверное? А вот и нет — из пакета paxutils.
А не busybox?
https://busybox.net/downloads/BusyBox.html
FreeBSD? монилит. NetBSD? монолит. OpenBSD? монилит.
Поясни. Ссылка мне ни о чем не говорит.
А не busybox?Если busybox, то это уже не GNU/Linux, извините.
https://busybox.net/downloads/BusyBox.html
Поясни. Ссылка мне ни о чем не говорит.UNIX состоит из отдельных маленьких программ, но все эти программы разрабатываются как часть единого целого. В общем репозитории. Взять какой-нибудь /bin/cat из Netbsd, а /bin/cut из OpenBSD — нельзя. В другой версии их собрать — часто нельзя тоже.
Так разрабатывался UNIX всегда, с момента его создания. Именно и только так можно добиться того, что «маленькие программы», о которых говорит философия UNIX — хорошо работают между собой. И ровно также разрабатывается systemd! Там нет «программы-монстра», там десятки отдельных утилит. Но… в общем репозитории, да.
Вот что является извращением — так это тот идеал, о котором говорит maledog: сотни пакетов, которые плохо согласуются между собой и которые разработчики дистрибутивов вынуждены склеивать между собой с помощью жвачки и изоленты. Получившийся франкенштейн — работает кое-как, но глючит — ужасно. Обновление версий какой-то компоненты превращается в муку.
Нужно ли превращать
systemd в такое себе дополнение к ядру Linux'а, включающему в себя всё-всё-всё? Наверное всё же не стоит. Крайности — они редко хороши. Но вот тому, что он заменяет собой десятки пакетов — можно только порадоваться. Иметь различия ради различий на ровном месте — большого смысла нет. Если хотите какой-то компонент заменить — ну сделайте себе fork systemd и меняейте. Хотя лучше вначале обсудить с разработчиками systemd — а вдруг ваша проблема решится добавлением 10 строк кода и они их примут к себе?Не умножайте сущности без необходимости, ни к чему это!
P.S. Некоторые инженерные решения
systemd мне самому не очень нравятся, мягко говоря, но пусть лучше так, чем десятки самых разных подходов и гадания на тему «а чегой-то они вот конкретно тут поиспользовали?»С десктопом действительно ерунда какая-то, но меня это мало волнует, у меня мак.
А на серверах нормальный инит нужен, это намного удобнее и предсказуемее, чем обвешиваться супервайзорами.
Fork? Fork не для демонизации, на самом деле. Демонизация — это такой старинный трюк, ритуальные приседания, повторяемые в каждой программе. New style daemons — отличная идея.
Я не фанат systemd, мне не нравится, как он написан, upstart мне нравится намного больше. Но в любом случае — это лучше, чем sysv.
А на серверах нормальный инит нужен, это намного удобнее и предсказуемее, чем обвешиваться супервайзорами.
Fork? Fork не для демонизации, на самом деле. Демонизация — это такой старинный трюк, ритуальные приседания, повторяемые в каждой программе. New style daemons — отличная идея.
Я не фанат systemd, мне не нравится, как он написан, upstart мне нравится намного больше. Но в любом случае — это лучше, чем sysv.
upstart за счёт своего event-drived подхода очень неудобен, когда у сервиса есть зависимость от нескольких других.
Не очень удобно, да. Но это проблема не подхода в целом (нормальный подход), а частная недоработка, вполне поправимая.
Но сейчас уже все равно смысла нет :)
Но сейчас уже все равно смысла нет :)
IMHO, это архитектурная проблема. Т. е. если у меня сервис 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'ы.
UFO just landed and posted this here
syslog
О, да, прекрасные syslog/rsyslog/syslog-ng. У вас они ни разу не теряли пару-тройку тысяч ключевых для post-mortem анализа сообщений лога в рамках burst'а при аварии? Удобно ли вам пихать в них логи программ, которые про syslog не знают и знать не хотят?
Уточните. Какие-такие программы, не говоря уж о демонах, не знают про syslog? А что они знают stdout?
Подавляющее большинство java-программ (если не обёрнуты специальными костылями типа daemon-tools), всё написанное в концепции 12factor, всякие вещи на rails, куча софта на python'е и т. д. и т. п. Обычно они все умеют в stdout и, часто, в файлы в том виде как это принято в соответствующей экосистеме.
Я вас удивлю, но и в java и ruby и python есть библиотеки для написания демонов и для нормального логирования. Но раз уж вы решили запустить эту программу, systemd не является такой же оберткой? В чем преимущество?
Расскажите мне про то, как без внешних костылей заставить стороннее java-приложение со сложным запуском писать в syslog, и как завести под него отдельный facility.
Заодно расскажите как на java установить обработчик SIGHUP без внешних костылей и/или нативного кода. Про процесс демонизации даже спрашивать неловко, но можете тоже поведать миру.
Без внешних костылей это как? Про daemonize слышали? Или в вашем понимании systemd костылем не является?
SIGHUP то вам зачем? Что программа незнающая про SIGHUP должна сделать при его получении? Чем вам поможет в этом systemd?
SIGHUP то вам зачем? Что программа незнающая про SIGHUP должна сделать при его получении? Чем вам поможет в этом systemd?
Который daemonize? Ссылку, сестра!
Если вы в курсе общепринятой обработки сигналов в *nix-демонах, то знаете, что обычно по SIGHUP переоткрывается файл лога, чтобы можно было его ротировать стандартным logrotate. Без использования внешнего (по отношению к jvm) обработчика можно использовать только внутренние интерфейсы sun/oracle jvm, что делает софт непереносимым. Т. е. нормальная программа, выполняющаяся на jvm, не может обрабатывать SIGHUP, даже если хочет про него узнать.
Systemd/upstart с моей точки зрения является стандартной частью окружения, которая отвечает за управление сервисами.
М-м Мы уже определились сам процесс sighup не понимает. Что в этом случае systemd делает?
Если дело только в ротации логов, так куча была программ — svlogd, multilog.
Иными словами ничего нового и полезного systemd пока не принес. но многое старое уже поломал. И как люди не умели пользоваться sysv и upstart, так же не будут уметь пользоваться и systemd.
Если дело только в ротации логов, так куча была программ — svlogd, multilog.
Иными словами ничего нового и полезного systemd пока не принес. но многое старое уже поломал. И как люди не умели пользоваться sysv и upstart, так же не будут уметь пользоваться и systemd.
systemd собирает логи процессов (не только того, которым он управляет, но и его дочерних), обогащает метаданными (в т. ч. доверенными типа timestamp'а, pid т. п.) и направляет всё это в journald. Далее оно может единообразно направляться в syslog/logstash/whatever со структурированными метаданными (без развлечений с парсингом логов регулярками). Далее с этим можно работать, выбирая нужную часть лога, например, по unit'у, а не только по имени процесса, как это обычно происходит с syslog.
Если говорить про svlogd, то минимальную функциональность он имеет (и он тоже не unix-way, на который так любят упирать противники systemd). Но сбор логов, скажем, дочерних процессов он не умеет.
multilog не использовал, за него не скажу. В стандартных репозиториях rhel/centos + EPEL его не видел, равно как и runit с его svlogd.
Что именно systemd поломал? Раз уж вы так упираете на этот тезис.
systemd собирает логи процессов(не только того, которым он управляет, но и его дочерних)
Поправочка. Дочерний процесс может быть вызван без передачи ему stderr и stdout — по умолчанию большинство так и делает. В этом случае systemd ничего не залогирует. Процесс может форкнуться и закрыть stdout. Процесс Может породить дочерний, который может в свою очередь форкнуться. Да масса ситуаций.
Никто никому не мешал запилить syslogd-mysql или syslogd-mongodb просто никому они были не нужны. И тут нате, оказывается бинаные логи — киллерфича systemd.
Дочерний процесс может быть вызван без передачи ему 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);А сам по себе fork даёт те же файловые дескрипторы в дочернем процессе (см. man 2 fork).
Перечитайте мое сообщение внимательнее. Форкаемся и закрываем stderr, stdin, stdout. Все нет их у дочернего процесса. В этом суть демона. Писать нужно в лог.
Интересно, а где же в man 3 syslog написано про структурированные логи и наличие доверенных атрибутов?
Странные термины. А RFC 5424? Вроде как все структурировано и формализовано.
UFO just landed and posted this here
Sign up to leave a comment.
SysV, Upstart, systemd в роли ассортимента граблей Debian/Ubuntu