Переход Ubuntu на Systemd

[drBatty]

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

хм, ладно, уели. Потом почитаю. Хотя всё равно не понимаю, где вам могла пригодится head в init.
я, кстати, юзаю обычно sed, а не head.

Я там выше привёл две ссылки для примера, когда недостаточное понимание принципов работы оболочки привело к ошибкам.

ну на эти ваши две лет за 30 можно набрать Over9000 ссылок про systemd, если он конечно столько проживёт. Неужели вы этого не понимаете? Всё равно shell намного более понятен сферическому в вакууме админу, и ошибок в шелле соответственно на порядок меньше будет.

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

ой, ну что там городить-то?

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

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

Ну и да, если демон mysqld пожрал всю память, и был убит OOM, то я не понимаю, что в такой ситуации может сделать администратор? Поднять? Дык он же после прогрева опять упадёт, разве нет? Не понимаю… Не, я быдлокодер, не админ, т.ч. расскажите, в чём там трудность, и как это всё на практике происходит? Почему администратору так сложно написать костылик на bash'е?

[Rootlexx]

При том, что код systemd написан на C.

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

Автоматически поднять упавшее - отличная идея, но кто сказал, что оно вот прям так и поднялось? Упало-то оно не просто от скуки, верно? Причины ведь были?

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

А, стало быть, и не поднимется, пока причины не устранены.

Скажем, segmentation fault при обработке определённых входных данных не означает автоматическую неработоспособность для других входных данных. (Хотя я признаю, что пример с БД не совсем удачный.)

[alv]

Не нужно рассчитывать, что можно вывалить своё или чужое мнение на техническом форуме в технической дискуссии

В стопятисотый раз спрашиваю: а причём здесь техническая дискуссия? Обсуждается новость. Новость ни в коем случае не техническая
типа в systemd'е придумали новую фичу - это требовало бы технического обсуждения теми, кто понимает, что это за фича
эта же новость сугубо политическая, касающаяся вовсе не разработчиков systemd, и даже не майнтайнеров дистрибутивов
касающаяся в первую очередь пользователей и применителей
и её обсуждение никакой техники не подразумевает

[Rootlexx]

Почему администратору так сложно написать костылик на bash'е?

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

• Пусть костылик представляет собой отдельный мини-скрипт в сессии администратора. Тогда при останове сервиса он будет запущен снова, если забыть прежде остановить скрипт-монитор.
  Кроме того, перезапуск сервиса будет происходить с другими переменными окружения, что может привести к неожиданным side-эффектам (это справедливо и при простом рестарте командой).
• Пусть теперь костылик в виде некоторого запускаемого в фоне цикла, постоянно проверяющего наличие процесса и стартующего его заново в случае необходимости, написан прямо в init-скрипте. Тогда необходимо переписать и логику останова, ибо сначала нужно прибить процесс-монитор, и только потом уже основной процесс, иначе он немедленно будет запущен снова.
  Кроме того, возникает вопрос синхронизации: при простом запуске цикла в фоне, который в свою очередь запускает основной процесс, нарушается точка синхронизации в виде ответвления (fork) по готовности, и основной скрипт может завершиться, а следующий - запуститься ещё до готовности данного сервиса принимать соединения, и если один из следующих сервисов зависит от данного, возникает состояние гонки, в результате чего можно получить проблему при загрузке, возникающую, скажем, в 10% случаев.

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

For those who don't agree, please try the exercise of writing systemd and
upstart configuration files for some typical daemon package and look at
the number of lines of code in both and the behavior in edge cases (daemon
already running, daemon running but with no PID file because something
else deleted it, daemon part of a dependency chain that shouldn't fire
until the daemon is actually listening to the network, correct exit status
for various failure conditions, stopping the daemon when there is a user
process with the same name as the daemon also running, and the other cases
Policy says one must handle). Now compare the length of time it took you
to make an init script correctly handle all those cases versus how long it
took to write the upstart or systemd configuration. (Note that I have
found, IIRC, two different edge-case bugs in /etc/init.d/skeleton while
working on Debian, so even if you start from that file, which is only
applicable to a relatively narrow range of circumstances, you can still
fail edge cases.)

Для решения части этих проблем есть разнообразные утилиты, различающиеся от дистрибутива к дистрибутиву, которые предварительно необходимо изучить в дополнение к собственно POSIX shell со всеми его подводными камнями.
Так что не всё так просто, и в этом и состоит причина того, что ни один из членов Технического комитета Debian не проголосовал за оставление sysvinit системой инициализации по умолчанию.

[drBatty]

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

я знаю. Эти нюансы давно и успешно решены: запускается костыль, который запускает демон, и не завершается, а так и крутится. Если демон надо остановить, останавливается костыль, который останавливает демон, и сам себя тоже завершает. Также костыль может делать рестарт демона. Ну короче получается полностью дублирующий скрипт(обычно надо start|stop|restart|status, и этого достаточно).

В принципе, сам демон может обеспечивать такой функционал, если он кривой by design.

Плюс вероятная необходимость перезапуска сервисов, зависящих от данного сервиса.

ага. А вот systemd это волшебным образом сам сделает, да?

Точно так же написание корректных init-скриптов кажется совершенно плёвым делом лишь на первый взгляд:

ну а речь вообще-то не о написании идёт. А лишь о костыле. Причём с очень большой вероятностью этот скрипт УЖЕ кем-то написан, и лежит в гугле, И вряд-ли у вас этих падучих демонов больше одного.

[Bizdelnick]

Rootlexx
А с какой стати система инициализации вообще должна заниматься перезапуском упавших сервисов? Нужен он админу - поднимет какой-нибудь monit. Не нужен - не поднимет. А если systemd будет это делать по умолчанию, админ и не узнает, что в системе что-то неладно.

[Hephaestus]

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

О сложности shell-скрптинга и простоте Си поёт Леннарт:

Нам часто приходится слышать жалобы, что процесс загрузки при использовании systemd очень сложен для понимания. Не могу с этим согласиться. Более того, я берусь даже утверждать обратное: по сравнению с тем, что мы имели раньше (когда для того, чтобы разобраться в загрузке, нужно было иметь хорошие навыки программирования на языке Bourne Shell (сноска:Чья привлекательность очень коварна и обманчива.)), процесс загрузки стал более простым и прозрачным.

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

Одно из ключевых достоинств systemd — наличие полного набора программ, необходимых на ранних стадиях загрузки, причем эти программы написаны на простом, быстром, надежном и легко поддающемся распараллеливанию языке C. Теперь можно отказаться от «простыней» shell-скриптов, разработанных для этих задач различными дистрибутивами.

А Вы подпеваете:

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

Знать shell нужно всё равно, хотя бы в его POSIX-подмножестве. Кроме того, надо знать многие не вполне очевидные вещи [1] [2].
В любом случае скрипт - это полноценная программа, которая притворяется конфигурационным файлом. Это даёт большую гибкость, но и большую сложность и больший простор для ошибок.

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

Утверждать, что Bourn Shell - сложный (коварный, имеет подводные камни), а Си - простой (коварством и подводными камнями не обременён) можно в двух случаях:
1. Человек знает в совершенстве тонкости и того, и другого, и "из двух зол выбирает меньшее"
2. Человек не знает толком ни того, ни другого, но сам при этом уверен, что знает.

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

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

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

[Bizdelnick]

Причём тут C vs. shell? sysvinit тоже написан на C. И инит-скрипты для него в принципе тоже можно написать на C, если уж шелл такой плохой. Только почему-то такое до Леннарта никому в голову не приходило. Одно из двух: или он гений, или он не учёл чего-то, очевидного для остальных.

[Hephaestus]

Причём тут C vs. shell?

При том, что в статье Леннарта - это основной мотив, оправдание всей его жизни работы над systemd:
Bourn shell непригоден для системы инициализации ввиду своей сложности и подводных камней, а ключевым достоинством systemd является, то, что он написан на C (там, надо полагать, ни сложностей, ни подводных камней нету).

[Rootlexx]

Эти нюансы давно и успешно решены: запускается костыль, который запускает демон, и не завершается, а так и крутится. Если демон надо остановить, останавливается костыль, который останавливает демон, и сам себя тоже завершает. Также костыль может делать рестарт демона. Ну короче получается полностью дублирующий скрипт(обычно надо start|stop|restart|status, и этого достаточно).

Не понял.
Костыль - init-скрипт, который не завершается? - тогда процесс загрузки также не завершится.
Костыль - init-скрипт, который завершается, запустив в фоне проверяющий цикл? - этот второй из описанных мной случаев, и приведённые нюансы им не разрешаются.
Костыль - подобие init-скрипта, но запускающийся не при загрузке, а вручную администратором? - этот вариант не разрешает приведённые в первом случае нюансы, и к тому же возникают вопросы запуска сервисов, зависящих от данного, а также корректного завершения работы при перезагрузке/выключении.
Так что для корректного решения задачи простым "костыликом на bash'e" дело не ограничится.

А вот systemd это волшебным образом сам сделает, да?

Сделает.

[drBatty]

Костыль - init-скрипт, который не завершается? - тогда процесс загрузки также не завершится.

почему "не завершиться"? Скрипт запускается как форк основного процесса.

А вот systemd это волшебным образом сам сделает, да?

Сделает.

зависимости узнает из хрустального шара?

[Rootlexx]

А с какой стати система инициализации вообще должна заниматься перезапуском упавших сервисов?

Не обязана, но хорошо иметь такую возможность.

А если systemd будет это делать по умолчанию, админ и не узнает, что в системе что-то неладно.

И ещё раз напоминаю, что:

Restart=
...
Takes one of no, on-success, on-failure, on-watchdog, on-abort, or always. If set to no (the default), the service will not be restarted.

Администратор узнает о проблемах из журнала. Кроме того, есть возможность запустить любой сервис при проблемах (см. man systemd.unit, директива OnFailure).

[/dev/random]

А ещё сегфолт сетевого сервиса может означать попытку взлома. Взломщик не угадал с первого раза рандомизированный адрес страницы памяти и вместо удалённого шелла получил сегфолт. Неужели кто-то хочет дать ему дофигаллион попыток в секунду?

[Rootlexx]

почему "не завершиться"?

Потому что вы так написали:

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

зависимости узнает из хрустального шара?

Нет, из сервис-файла.

[Rootlexx]

Неужели кто-то хочет дать ему дофигаллион попыток в секунду?

man systemd.service, директивы RestartSec (по умолчанию 100 мс, так что уже не "дофигаллион попыток в секунду"), StartLimitInterval, StartLimitBurst.

[Vexhin]

У меня Ubuntu и OpenSUSE в дуалбуте. Не могу сказать по ощущениям, что быстрее грузится. Зато в Сусе после появления рабочего стола сразу начать что-либо делать нельзя. Даже меню не открывается. После секунд 10-15 система оживает.
Так что никакой ускоренной загрузки, зато мелкий и раздражающий обман с фоновой подгрузкой. Ну и зачем этот системд?

[Rootlexx]

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

О сложности shell-скрптинга и простоте Си поёт Леннарт

Не уводите дискуссию в сторону. Речь изначально шла совсем не о том, и вообще не с вами.

Поскольку заранее нельзя сказать, поднимется или нет, то всё равно нужен контроль со стороны админа.

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

[eddy]

Ну и зачем этот системд?

Чтобы гнуть пальцы и поливать помоями sysvinit же!

[Rootlexx]

И инит-скрипты для него в принципе тоже можно написать на C, если уж шелл такой плохой. Только почему-то такое до Леннарта никому в голову не приходило.

upstart, launchd...

[Hephaestus]

Не уводите дискуссию в сторону. Речь изначально шла совсем не о том, и вообще не с вами.

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

Смотрю, вы переключились в режим генерации чуши.

Не берите на себя слишком много обязательств.

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

Контроль админа здесь затем, что упавший сервис - его прямая профессиональная забота. И нормальный админ не будет надеяться на автоматический перезапуск (который, очевидно, сработает не во всех случаях и ещё неизвестно, как вообще сработает), а сам проконтролирует устранение причин падения и последующее поднятие сервиса. Отсюда ясно, что автоматический перезапуск нафиг никому не упёрся.
На всякий случай ещё раз напомню: За шесть лет я видел всего один случай, когда автоматический перезапуск упавшего демона действительно был бы полезен. Вряд ли в Вашей практике таких случаев сильно больше.

[Rootlexx]

У меня Ubuntu и OpenSUSE в дуалбуте. Не могу сказать по ощущениям, что быстрее грузится. Зато в Сусе после появления рабочего стола сразу начать что-либо делать нельзя. Даже меню не открывается. После секунд 10-15 система оживает.
Так что никакой ускоренной загрузки, зато мелкий и раздражающий обман с фоновой подгрузкой. Ну и зачем этот системд?

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

[Hephaestus]

Когда я начал читать статьи Леннарта, я надеялся найти там подтверждение того, что я неправ.
Я искренне хотел убедиться в своей неправоте.
Но нет, оказалось наоборот.
Леннарт по всем правилам начинает с обоснования актуальности решаемой задачи. И далее предлагает своё решение.
Беда однако в том, что актуальности-то как раз и нет. Существующая система инициализации работает.
Вот если бы не работала и люди бы жаловались, что пора что-то делать, дальше так уже невозможно... тогда да, задача была бы актуальна.
А так - это больше похоже на "придумаем проблему и героически её решим". А потом ещё и будем убеждать всех, что это решение им очень нужно.

[Vexhin]

Да, разные. И даже разные версии: ubuntu 10.04 GNOME2 (спасибо третьегному, отучил меня от навязчивой мании гнаться за последними версиями) и opensuse 13.1 kde.

Кстати, только что перлогинился в KDE ubuntu - не так и тормозило при загрузке.

На параллельный старт мне пофиг. Мне интересно - почему мне показывают рабочий стол, когда он не готов к работе? Пусть бы крутилась заставка подольше, но пусть честно показывают верстак, только когда он уже готов.

[drBatty]

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

всё верно: костыль крутится и следит за демоном, который падает. Как только демон падает, костыль(который крутится) его(демона) подымает, и крутится дальше.

зависимости узнает из хрустального шара?

Нет, из сервис-файла.

и чем это хуже "из файла *conf"?

так что уже не "дофигаллион попыток

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

Зато в Сусе после появления рабочего стола сразу начать что-либо делать нельзя. Даже меню не открывается. После секунд 10-15 система оживает.

в 2001ом году в WinXP™ у меня было тоже самое.

[Rootlexx]

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

Вы влезли со своим сравнением C и shell, о котором я вообще не говорил, и требуете у меня ответа. Попутно приводите в своём контексте мои цитаты, в которых речь вообще-то ведётся совсем о другом, на что я вам неоднократно указал.
Передёргивания и подмена понятий не лучшая манера вести дискуссию, так что да, замечания по ведению дискуссии у меня к вам есть.

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

Ещё раз, последний, вам объясняю, что "устранение причин и последующее поднятие" возможно лишь в вашем выдуманном мире. В реальном же, когда работать нужно здесь и сейчас, никто не будет выслушивать ваше лепетание про то, что вам-де техподдержка ещё не ответила, баг не исправлен, и потому денёк-другой работать ну никак нельзя.

[drBatty]

Зачем здесь контроль админа? Поднимется - хорошо, не поднимется - плохо.

этот приём называется "подмена понятий". Используется в социальной олимпиаде.

В данном случае "подымется/не подымется" роли НЕ играет. То, что упал — УЖЕ авария. И нужно пинать администратора, что-бы он оторвал жопмышку от коврика, и шёл разбираться.

[Rootlexx]

Vexhin
Помнится, встречал жалобы на подобные симптомы в KDE. Если правильно помню, дело в Plasma. В любом случае к моменту появления рабочего стола (а KDE грузится весьма неторопливо) все сервисы уже должны успеть загрузиться, так что маловероятно, что дело в параллельной загрузке и systemd в частности.

[drBatty]

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

и ещё не известно, надо-ли вообще подымать этот демон? Может это не имеет смысла(память кончится, и демон всё равно упадёт) или того хуже(была попытка атаки. Пока неудачная).

Вы влезли со своим сравнением C и shell, о котором я вообще не говорил

за то говорил Леннарт.

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

вы действительно называете "работой" ситуацию, когда какой-то жизненно важный демон регулярно падает?

а KDE грузится весьма неторопливо

это вы наверное про версию 4.2

[Rootlexx]

всё верно: костыль крутится и следит за демоном, который падает. Как только демон падает, костыль(который крутится) его(демона) подымает, и крутится дальше.

Ну вот я вас и спрашиваю, как и когда запускается данный костыль. Желательно поподробнее.

и чем это хуже "из файла *conf"?

Не очень понимаю, о чём вы. Я ни с какими "файлами *conf" не сравнивал.

какая разница сколько? Враг может в любое удобное время ломать ваш сервис и его ронять, пока не узнает, как добиться не сегфолта а нормально и годно порутать вашу систему.

А ещё он может ломиться в ваш ssh, подбирая пароль/ключ. Вот только что в данном случае, что в обсуждаемом примере, с паузой между попытками и ограничением на их количество делать это он будет вечность.

А вы об этом даже не догадаетесь, ибо у вас процесс взлома автоматизирован.

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

[Hephaestus]

Вы влезли со своим сравнением C и shell, о котором я вообще не говорил, и требуете у меня ответа. Попутно приводите в своём контексте мои цитаты, в которых речь вообще-то ведётся совсем о другом, на что я вам неоднократно указал.

Так или иначе Вы с Леннартом поёте в один голос. А точнее, Вы повторяете его аргументы.
Я не говорю, что это плохо, просто это бросается в глаза, после прочтения статьи.

Ответов я от Вас не требую. С какой стати? Не хотите - не отвечайте, игнорируйте мои посты.

Ещё раз, последний, вам объясняю, что "устранение причин и последующее поднятие" возможно лишь в вашем выдуманном мире.

Да неужели? Вы же не собираетесь развлекать меня тем, что в реальном мире причины аварии никто не устраняет?

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

Прекрасно. Только не забывайте, что в реальном мире, где нужно работать здесь и сейчас, упавший демон не поднимется только потому, что у Вас там какая-то автоматика прикручена. Плевать он на неё хотел.
Автоматика его поднимает, а он опять падает. Она его опять поднимает, а он опять падает. И так будет до бесконечности. Ибо причина падения никуда не делась. И он будет продолжать падать. И плевать ему на то, что Вам нужно работать здесь и сейчас. Это гораздо более вероятная ситуация, чем та, в которой автоматическое поднятие демона действительно поможет.