Новый релиз systemd 195

Вот именно в этом случае cgroups — это не решение, а костыль.

нет, это решение.

Любой рутовый процесс может прыгнуть в другую группу, и его уже не найдут.

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

Пример: что будет, если в systemd перезапустить сервис sshd?

я вот без понятия. Но это не единственный вариант решения. При этом когда НАДО убить всех наследников (rc-service sshd stop) это может быть хорошим решением, если sshd сфейлит всех убить само.

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

Бывает и такое. Если не смог пробить и затвердить политику, по неизменности ит-ландшафта без необходимого тестирования, включающего некороткую опытно-промышленную эксплуатацию под полной нагрузкой (даже это иногда не помогает, хотя бы по причинам невозможности загрузить процедурой закрытия года систему, например в июле), то тут ССЗБ.

Заметьте - закупили люди систему работающую только под линухом. Вот что это если не высасывание из пальцев. Теперь ответ системд подходит под вопрос.

Море способов

О! Вагон велосипедов для решения одной, простенькой, по большому счёту, задачи - остановка/запуск процессов. Может стоило бы уже написать 1 программу, которая делает это хорошо?

Какое отношение перезапуск отдельно взятых упавших сервисов имеет к системе инициализации

Элементарно, ватсон. В этом нашем «юниксвее» «инициализация» и есть «запуск отдельно взятых процессов». Зачем использовать для этих, точнее, как мы выяснили, «этой», задачи ≥2х систем?

Можно, конечно, возразить против полезности интегрированной ф-ии остановки. Правда, нам придётся придумывать какой-то способ для системы опускания узнать, что именно останавливать(как то костыли типа /var/run/*.pid - некрасиво, ненадёжно и плохорасширяемо). Например http-сервер в составе системы запуска мог бы сообщать PID-ы. Всё же проще, кажется засунуть остановку внутрь, тем более в init-е она есть.

О! Вагон велосипедов для решения одной, __простенькой, по большому счёту, задачи - остановка/запуск процессов__.

бугагага.

Может стоило бы уже написать 1 программу, которая делает это хорошо?

может. только сначала сформулируй, что не устраивает в имеющихся

Чтобы оставить исключение исключением?

Ты действительно настолько наивен? Почитай разные рассылки про исправления ошибок. Исключением является программа, ведущая себя «правильно». Обеспечить это для _всех_ возникающих IRL случаев довольно трудно, а программисты не настолько идеалистично настроены, чтобы этого добиваться. Такова реальная жизнь; большинство программ падают/зависают/тормозят когда им этого захочется; и хорошо, если система мониторинга скажет об этом дежурной смене, и тем удастся быстро вычистить/перезапустить всё нужное(не тронув всё ненужное). И да, для разборок лучше пользоваться корками и логами, а не лежащим сервисом.

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

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

сформулируй, что не устраивает в имеющихся

init: нет возможности остановить/запустить одиночный сервис; неустранимо без полной переделки. init+initscripts: при перестарте демонов новые запускаются с auid оператора, догадайся потом, что это не он систему ломает, а демон работает; неустранимо by design. daemontools: это будет уже минимум 3я система управления в канонической поставке (если inetd не считать) — догадайся, как остановить/запустить, скажем, хзчтоd; к тому же, когда я прошлый раз смотрел, они были настолько монструозны, что я предпочёл свой велосипед напартачить.

Про предпоследние заменители, типа апстарта, пока ничего не скажу - не успел достаточно поработать.

я нифига не понял, что за претензия к демонтулзам, хотя, честно, попробовал

бездумное переподнимание может наделать проблем еще больше, чем было

А может и сервис поднять. И без того, чтобы тебя оторвать от какого ты предпочитаешь пола.

почему, скажи, демонтулсы не ставят на каждый второй сервер

Не каждый второй сервер гоняет достаточно критичные к времени простоя программы - при возможности таки интересно разобраться. Или потому, что ребут системы чистит всё намного лучше. Или потому, что они некрасивы(IMHO). Или потому, что не каждый сервис адекватно ложится в их систему управления (у меня минимум 2 таких, которым, кажется, никакой бебиситтер не поможет). И в дистрибутиве его нет, сопровождать лень.

что за претензия к демонтулзам

У меня уже есть init, initscripts и xinetd(и, местами,heartbeat) — ставить четвёртого/пятого - перебор.

А может и сервис поднять. И без того, чтобы тебя оторвать от какого ты предпочитаешь пола.

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

Не каждый второй сервер гоняет достаточно критичные к времени простоя программы

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

Или потому, что ребут системы чистит всё намного лучше

а, виндовс вей, все понятно

Или потому, что не каждый сервис адекватно ложится в их систему управления

например?

у меня минимум 2 таких, которым, кажется, никакой бебиситтер не поможет

от кривых сервисов костыли не спасут, о чем и речь

И в дистрибутиве его нет, сопровождать лень.

у меня есть сервер на дебиане с демонтулсами, ставил из официальной репы.

а системд, значит, панацея?

О! Вагон велосипедов для решения одной, простенькой, по большому счёту, задачи - остановка/запуск процессов.

Задача не одна. Их много, каждый сервис может запускаться и останавливаться по-разному. Некоторые сервисы могут плодить несколько процессов (см. httpd), другие создавать гигантское дерево (sshd), третьи вообще работать без процессов (iptables). Кроме того в реальной жизни всем пофиг, запущен процесс или нет, волнует только вопрос: работает он или нет. И на этот вопрос init ответить не может, да это и не его задача. Зато так ненавистные леннарту initscripts могут ответить на этот вопрос, и, пожалуй, никто не ответит на него лучше.

Может стоило бы уже написать 1 программу, которая делает это хорошо?

Может стоило уже написать 1 язык программирования? Может стоило уже написать одну операционную систему? Может стоило уже написать один текстовый редактор? Может стоило уже написать один оконный менеджер? И т.д. Теперь понятно? Для разных задач — разные решения. Разным людям удобны разные инструменты в разных ситуациях. И никакой леннарт не имеет права указывать другим, чем им пользоваться. Собственно, он и не указыват, он просто рекламирует с трибуны, а ему верят.

Элементарно, ватсон. В этом нашем «юниксвее» «инициализация» и есть «запуск отдельно взятых процессов».

Верно. Однако перезапуск упавших процессов к инициализации уже не относится. Слежение за падающими процессами — отдельная задача, которая должна выполняться отдельной утилитой, той, которая делает ее лучше всего.

init: нет возможности остановить/запустить одиночный сервис; неустранимо без полной переделки.

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

init+initscripts: при перестарте демонов новые запускаются с auid оператора, догадайся потом, что это не он систему ломает, а демон работает; неустранимо by design.

Интересно, для чего тогда изобрели команды service/invoke-rc.d? И, кстати, что за auid?

daemontools: это будет уже минимум 3я система управления в канонической поставке (если inetd не считать) — догадайся, как остановить/запустить, скажем, хзчтоd;

`svc -d` что-ли?

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

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

Демонтулз? Монструозны?! Может, это какие-то не те демонтулзы были? :)

Вообще, поделки DJB можно обвинять в чём угодно: в том, что написаны на идиотском по стилистике C, в том, что конфигурационные файлы имеют странноватый синтаксис, в том, что для наворотов конфигурации придётся писать уникальные и часто невоспроизводимые shell-скрипты, увязывающие требуемые программы в хитрозагнутую под особенности задачи и/или окружения цепочку вызовов. Но оно всё - как автомат Калашникова, если тебя один раз на... научили его разбирать-собирать, то потом ты будешь делать это хоть с завязанными глазами, хоть со связанными руками.

Кроме того в реальной жизни всем пофиг, запущен процесс или нет, волнует только вопрос: работает он или нет. И на этот вопрос init ответить не может, да это и не его задача.

Стакан портера этому господину!

можно терять не только на простое

Правильно; но это ведь не повод не минимизировать потери от простоя, когда это безопасно?

от кривых сервисов костыли не спасут

Точнее: не каждому кривому сервису любой костыль подойдёт. Но костыль, подходящий большинству иметь полезно, или как?

системд, значит, панацея

Ты сказал.

Правильно; но это ведь не повод не минимизировать потери от простоя, когда это безопасно?

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

Точнее: не каждому кривому сервису любой костыль подойдёт. Но костыль, подходящий большинству иметь полезно, или как?

утомил. демонтулз подходит большинству. опровергни.

Ты сказал.

знак вопроса ты специально не увидел?

демонтулз подходит большинству

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

Задача не одна

Это как сформулировать. Давай, к примеру, посмотрим на initscripts от приведенных тобой iptables, httpd, sshd. Там, AFAIR(посмотреть сейчас негде, дома уже systemd) 90% копипейст, несмотря на то, что они «такие разные». Т.ч. я, пока, остаюсь при мнении, что задача запуска таки одна.

Задачи мониторинга работоспособности разные; правда у них есть одна общая черта - согласно конвенции процесс, завершившийся со status<>0 - не работает; можно/нужно ли его перезапускать - зависит от процесса, т.ч. должно либо конфигуриться(как в init и systemd), либо выноситься во внешнюю прогу(как в daemontools). Первое неюниксвейно, второе захламляет список процессов. Я, к примеру, молюсь реже, чем ps запускаю, т.ч. предпочитаю первое. YMMV.

Задачи остановки, согласно канонам, должны были бы быть одинаковыми, kill(2). Но тут опять компромисс - есть ядерные сервисы, ему недоступные. Тут мы вынуждены приспосабливаться к особенностям монолитной архитектуры ядра, и включению туда чего ни попадя. И есть программы, не способные корректно остановиться, когда попросят. Эти недостатки _других_ программ приводят к тому, что задача остановки вынуждено заменяется задачей старта(скриптов зачистки). А поскольку стартовать уже умеет система инициализации, логично это ей и поручить.

Итого, и инит и системд выглядят _одинаково_ гов^Wкомпромисными реализациями, а демонтулс - кошерным геморроегеном.

перезапуск упавших процессов к инициализации уже не относится

Опять же, задача не относится. Но программа, которая уже умеет делать остановку и запуск(как мы выяснили, это относится к инициализации), является первым кандидатом на роль перезапускалки.

runlevel-ы решают эту проблему ...

... если сервисов не больше 4(в линуске чуть больше, порядка 7)... Тебе столько хватает?

что за auid

man pam_loginuid. Очень нужная параноикам штука.

svc -d` что-ли?

Нет; init 4 или service whatewer или что там с xinetd или svc -d или su - юзер svc -d.

попроще, чем systemd

Помнишь про "... не проще, чем это необходимо"?

Система инициализации это же система, которая должна весь жизненный цикл сервиса обслуживать, останавливать его, запускать, перезапускать, перезагружать конфиг, поддерживать сервис в доступном состоянии, а значит если он упал, то перезапускать его. На самом деле система инициализации это целый комплекс, init лишь малая его часть. И лучше этот комплекс будет состоять из хорошо интегрированных друг с другом компонент, чем склеиваться скотчем из того, что есть.

нет. то про, что ты говоришь это минимум PID-1, supervision, service-management, и если ты хочешь их склеивать в одно, при этом такие задачи как: 1) перезагрузка конфига, 2). поддержание сервиса в доступном состоянии, не должны и не могут решаться в общем случае. Так как а). задачей автоматической перезагрузкой конфига должен заниматься только сервис, б). неавтоматическая перезагрузка лога это хук restart() {}, в котором пишется сервисноспецифичное решение. Поддержка сервиса в доступном состоянии (точнее проверка его доступности) это вообще задача системы мониторинга, т.к. адекватная проверка доступности в некоторых случаях может быть сложнее, чем весь инит комплекс. Про перезапуск сервиса и почему это плохо автоматом, и к чему это может привести тут уже писали 100 раз.

Итого, что есть:

PID-1: получение pid-1 от инициализатора системы, поддержание системы в норм состоянии, перецепление процессов без родителей, дроп в resque shell в случае проблем, отдача управленяю финализатору системы, (бонусы), поддержка init уровней (?),

Supervision: наблюдение за созданными сервисами, перезапуск (или хук) в случае падения, (бонусы)

Service-management: запуск сервиса и зависимостей, переход на разные уровни сервисов, показ статуса сервиса, выполнение команд сервиса, (бонусы)

Лог-сервис: сервис или куча процессов осуществяющих логирование.

Есть интересные реализации, которые пихают дефолтную систему логирования и супервижн в init систему, но и у них идёт разделение PID-1 -> хранитель-сервиса -> сервис.

Ну и самое главное, нужно уметь менять (отключать) любую компоненту для любых наборов сервиса, для того, чтобы можно было заменить её на ту, которая больше подходит в конретном случае.

Система инициализации это же система, которая должна

Откуда инфа?

Поттеринг напел (

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

Разрезать супервизор и pid1 можно только если в этот самый pid1 засунуть IPC для сообщения супервизору об убитых чайлдах. Там в любом случае будет какой-то протокол, и скорее всего эта вся борода будет в одной поставке идти. Я не думаю что в этом есть смысл. Вопрос о «неубиваемости» pid1 в данном контексте не имеет смысла: в случае стейтфулл системы мониторинга сложным компонентом будет именно она, и выход её из строя все равно грохнет основную функциональность.

Так что я не вижу особого смысла отделять pid1 от супервизора. Это усложнит систему и не решит проблем с устойчивостью.

Другой вопрос, что может быть было бы логичным использовать супервизоры с внешним стейтом, как openrc, например. Но у нас уже есть такая система, и systemd хейтеры могут развивать её

умалчивании того, что потеряете

и что же именно пользователи потеряют от перехода на systemd? конкретно, по пунктам, пжлст.

Посмотри на launchd, который just work, and work fine!

Разрезать супервизор и pid1 можно только если в этот самый pid1 засунуть IPC для сообщения супервизору об убитых чайлдах.

s6 и даймонтулзы вот не объединяют. И в s6 инит на 500 строк си кода с комментариями при этом :). А решений несколько: 1). запускать прослойку 2). привязываться к процессу сокетом и слушать как он сдохнет. 3). реальная магия. В случаях сложнее agetty нужно последнее :)

Другой вопрос, что может быть было бы логичным использовать супервизоры с внешним стейтом, как openrc, например.

openrc это только менеджер сервисов, он не решает ни задач s-vision, ни задач инита.

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

А решений несколько: 1). запускать прослойку 2). привязываться к процессу сокетом и слушать как он сдохнет. 3). реальная магия

Что самое смешное, неработающий демон не обязательно должен умереть как процесс :)

запускать прослойку

Затратно, но реально

привязываться к процессу сокетом и слушать как он сдохнет

Не совсем понимаю как это должно работать, тем более некоторые идиотские сервисы любят делать for (....) close(fd).

openrc это только менеджер сервисов, он не решает ни задач s-vision, ни задач инита.

Про супервизор я зря написал, да. openrc был приведен как пример системы со стейтом и с внешним хранением

никто так и не сказал, почему именно он должен это делать

и не скажет. потому что он не должен этого делать. но может. такая себе приятная мелочь. достаточно разжевал?

Из-за приятной мелочи написать тонну кода? Вот так подход :)

Кстати, вот ещё так никто и не назвал, что именно у них падает постоянно. У меня вот на днях mysql упал, потому что inode кончились на винте. Вот и какой смысл был бы в таком случае перезапускать его постоянно? Пользы нет, а вред есть.

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

Хз, может нормально, может нет. Мне в дебиане по /etc/init.d/somed status говорят статус, как ни странно.

зачем вы юродствуете?

А зачем выдавать за определение собственные догадки?

А с другой стороны, вот лично вас не напрягает, что стоит чему-то довестись до ума, как это ломают и начинают писать заново с непонятными людям целями? Меня вот очень настораживает эта тенденция.

стоит чему-то довестись до ума, как это ломают

Не «ломают», а «не пишут дальше». Но с таким количеством обожателей sysvinitу-то такая судьба точно не светит.

Именно ломают, агрессивно проталкивая. sysvinit то не умрёт, но толку от него, если перестанут писать init-скрипты?

К тому же, я всецело ЗА упрощение init-скриптов, но действительно ли это революционное изменение, а не эволюционное?

Я вот смотрю как нынешние браузеры с их SaaS бодро шагают по граблям, которые были пройдены в становлении современных оконных систем, и становится грустно. Сколько времени люди теряют на этом даром. Та же история, скажем, с андроидом... Много такого. Зачем это всё?

агрессивно проталкивая

а, высылают отряд эсэсовцев со шмайсерами по адресу проживания maintainerов арчлинукса и прочих Предателей Unix-Way? понимаю, да, тут сложно отказаться.

перестанут писать init-скрипты

то есть sysvinit c батниками необходим толпе народу, но в то же время писать батники внезапно станет некому? вы ничего не упускаете?

Я называл в каком-то очередном срачетреде. synergyc, emacs и скайп - вот то что у меня регулярно перезапускается после громкого краша :D

Ну и пульс за компанию. Правда он вроде не падает

а, высылают отряд эсэсовцев со шмайсерами по адресу проживания maintainerов арчлинукса и прочих Предателей Unix-Way? понимаю, да, тут сложно отказаться.

зачем вы юродствуете?

то есть sysvinit c батниками необходим толпе народу, но в то же время писать батники внезапно станет некому? вы ничего не упускаете?

Писать мало. Вот что вы посоветуете пользователям arch, которые не хотят systemd? Форк?

o_O

нет, скайп, конечно, ещё то говно, но причём тут, казалось бы, init?

Я не знаю. Но у меня системде его перезапускает. Такие дела