Переход Ubuntu на Systemd

[Rootlexx]

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

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

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

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

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

Я не Леннарт. Пишите по адресу lennart@poettering.net.

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

Это печальная данность. Когда стоит выбор между "ждать исправления и ничего не делать" и "ждать исправления, а пока хоть как-то работать", обычно выбирают последнее.

[Rootlexx]

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

Выделю, чтобы было понятнее:

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

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

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

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

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

- это неверно для хорошо протестированного ПО в, скажем, Debian stable.

[drBatty]

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

ну я помнится такой делал для amuled, который постоянно падал(пока ошибку не исправили). Запускался он

Код: Выделить всё

sudo -u amule amule.sh

из /etc/rc.d/rc.local

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

какая разница? У вас берёт из какого-то файла, и у меня из какого-то файла. Чем ваш способ принципиально лучше?

А ещё он может ломиться в ваш ssh, подбирая пароль/ключ.

ну и пускай ломится. Пусть подбирает. Скорее Нева потечёт в обратную сторону, чем он подберёт. А при чём тут падение демона?

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

это забота демона на самом деле. Ну или там какого-то костыля типа fail2ban'а.
при чём тут init — для меня загадка.

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

всё это при желании можно сделать с помощью шелла.

[drBatty]

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

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

Я не Леннарт.

но таки защищаете здесь его решение. А у Леннарта это один из основных аргументов "sh тормозной, сложный, непонятный, и потому его надо заменить". Если вы не согласны с Леннартом в этом пункте, тогда объясните: что же даёт такого этот ваш systemd? Перезапускать демоны я и bash'ем могу. Параллельно грузить — тоже, в слаке так и сделано, mysqld загружается вместе с KDE например, т.е. bash-скрипт не ждёт, пока mysqld запустится, а сразу запускает xinitrc.kde.

Это печальная данность. Когда стоит выбор между "ждать исправления и ничего не делать" и "ждать исправления, а пока хоть как-то работать", обычно выбирают последнее.

не, понятно, что возможность костылей должна быть. Но она и так есть. Я не вижу проблемы. Про демон amuled я уже рассказывал, не такой он уж и критичный, и ошибку не могли года два исправить. И эти годы его подымал мой простой скрипт, ещё и логи ротировал. Сейчас не падает. То-ли памяти полно, то-ли код поправили наконец.

[Red Gremlin]

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

Идея systemd — не переписать init-скрипты на C, а заменить большинство из них (те, которые просто запускают внешний демон или какую-нибудь последовательность внешних команд) текстовыми конфигами, а те скрипты, которые делают что-то более сложное, разделить на собственно содержательную часть и на текстовый конфиг системы инициализации (идея вполне здравая. никого не смущает, что в sysvinit в /etc/init.d порой лежат целые программы на шелле в десятки килобайт и сотни строк кода?). И Си тут постольку-поскольку Леннарт сотоварищи пишут на си и заодно решили содержательную часть на си переписать так, как им видится правильнее, раз уж всё равно скрипт переписывать, никто не мешает делать на баше или на питоне.

Только почему-то такое до Леннарта никому в голову не приходило.

Может и приходила, я ещё 15 лет назад думал, что система инициализации на баше — это велосипедизм и лучше бинарные сервисы и текстовые файлы для их тонкой настройки. Только без дистрибутива за спиной эти мысли вынуждены оставаться мыслями — кто-то же должен мантейнить все эти толпы демонов. За Леннартом был Red Hat.

Одно из двух: или он гений, или он не учёл чего-то, очевидного для остальных.

Просто без systemd или чего-то похожего, ориентированного на бинарные запускалки, у мантейнеров демонов просто выбора большого не было — писать с нуля слишком трудоёмко, проще скопипастить и адаптировать существующий скрипт для похожей задачи. С появлением systemd делать это проще — делаешь десяток #include и значительная часть проги уже готова.

[Hephaestus]

это неверно для хорошо протестированного ПО в, скажем, Debian stable.

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

Ещё пример. Есть некий процесс А. В какой-то момент он глючит и выжирает 95% памяти. В результате падает важный процесс Б, которому памяти стало недостаточно. Процесс А продолжает висеть. Автоматика пытается поднять процесс Б. Получится? Нет, ибо память занята. Нужно прибить процесс А.

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

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

[Red Gremlin]

Например, по недосмотру неверно настроена (или совсем не настроена) ротация логов. В резултате какой-нибущь лог распухает, кончается место на разделе.

В случае systemd и даже самого пьяного и тупого админа ситуацию спасёт то, что SystemKeepFree по умолчанию равна 15% от размера файловой системы. А если админ сознательно поменял дефолт на 0, то от него можно ожидать и rm -rf /*. От идиота с правами рута ни один юникс толком не защитит.

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

А чем ситуация "Не рестартануло, потому что не смогло" от ситуации "не рестартануо, потому что не пыталось" принципиально отличается? Чем так лучше не пытаться рестартовать?

[Rootlexx]

А при чём тут падение демона?

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

всё это при желании можно сделать с помощью шелла.

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

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

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

но таки защищаете здесь его решение.

Не смешивайте всё в одну кучу. В данный момент в sysvinit shell используется для:

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

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

[Bizdelnick]

Идея systemd — не переписать init-скрипты на C, а заменить большинство из них (те, которые просто запускают внешний демон или какую-нибудь последовательность внешних команд) текстовыми конфигами

Я в курсе. Если не дошло, то суть моего коммента сводилась к тому, что systemd vs. sysvinit - не то же самое, что C vs. shell.

а те скрипты, которые делают что-то более сложное, разделить на собственно содержательную часть и на текстовый конфиг системы инициализации (идея вполне здравая. никого не смущает, что в sysvinit в /etc/init.d порой лежат целые программы на шелле в десятки килобайт и сотни строк кода?)

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

[Red Gremlin]

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

Это в каких таких дистрибутивах скрипт запуска 1C-server отделён от init-скриптов?

[Bizdelnick]

Это в каких таких дистрибутивах скрипт запуска 1C-server отделён от init-скриптов?

А в каких-таких дистрибутивах он есть в официальных репозиториях? Не надо сюда кусок левого быдлокода приплетать, пожалуйста.

[Hephaestus]

В случае systemd и даже самого пьяного и тупого админа ситуацию спасёт то, что SystemKeepFree по умолчанию равна 15% от размера файловой системы.

Этого я не знал. Теперь знаю. Неясно только, как это поможет.
Смотрите сами: Давайте возьмем для простоты арифметики цифру 100Мб.
Итак, есть свободное пространство объемом 100Мб. SystemKeepFree резервирует 15Мб из этой сотни. И что?
При таком раскладе распухающий лог займет 85Мб и после этого сервис упадет, потому что больше места нет, остальное зарезервировано. Если же отдать эти зарезервированные мегабайты, то распухающий лог займет все 100Мб и дальше сервис всё равно упадёт.
Не важно, какой именно сервис - может, тот, чей лог распухает, а может соседний, не один, так другой, всё равно упадёт. Дальше должен сработать автоматический перезапуск, который ровным счетом ничего не даст, ибо сервису нет места для работы.

А чем ситуация "Не рестартануло, потому что не смогло" от ситуации "не рестартануо, потому что не пыталось" принципиально отличается? Чем так лучше не пытаться рестартовать?

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

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

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

Кстати говоря, вот эта предлагаемая автоматика и вообще идея systemd - это... как бы это сказать, подмена задачи. Придумывается автоматический перезапуск сервисов (который нужен раз в год), всякие там сервис-файлы с упрощённым синтаксисом, которые вообще нафиг не нужны, ибо и без них всё работает, И всё это вместо того, чтобы повышать уровень грамотности админов.
Лучше б учились скрипты писать нормально, тогда и демоны падать не будут, и систему инициализации переделывать не придётся. Но нет, куда там!
Если бы существующая система не работала, тогда дело другое.
Но она работает, вот ведь какая незадача! Чиним то, что не ломалось.

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

[serzh-z]

что свидетельствует о чём? - правильно

И о чём же свидетельствует закидывание отходами автора ПО, которое пользуется популярностью у разработчиков дистрибутивов? =) Это прямо как ругать подлого Калашникова.

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

Это реально проблема. Даже на домашней системе.

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

Это просто оголтелый и очень неумный, для инженерной темы, троллинг. =)

Может и приходила, я ещё 15 лет назад думал, что система инициализации на баше — это велосипедизм и лучше бинарные сервисы и текстовые файлы для их тонкой настройки.

Ребята из Apple об этом тоже, как видно, подумали. =) Мне эта идея не кажется велосипедной, она простая и гибкая, но с приходом Linux в устройства, выглядит очень архаичной: пару лет назад мы делали один USB-донгл, внутри которого крутился Linux, и bash-скрипты внутри выглядели очень коряво.

Но она работает, вот ведь какая незадача! Чиним то, что не ломалось.

Она работает лишь в очень простых ситуациях. Для обычного пользователя - её достаточно.

[drBatty]

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

ну и зачем её дублировать? В sshd всё это есть, и работает вроде.

всё это при желании можно сделать с помощью шелла.

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

ответ: да, нужно, причём именно на shell'e. Не забывайте, речь у нас идёт о срочной работе: ВНЕЗАПНО рухнул какой-то демон, нужно по быстрому слепить костыль причём администратору, которой вообще говоря не обязан разбираться в C/C++ или ещё чем-то подобном. Времени ждать помощь от разработчиков демона НЕТ, нужно взять и сделать, срок вчера. В данной ситуации shell поджходит как нельзя лучше, администратор просто обязан его знать, и уметь быстро слепить требуемый костыль, который как-то будет подымать демон, пока его не вылечат. Ситуация не только срочная, но и нестандартная, потому стандартный systemd тут не подходит, там просто не будет таких особых правил для поднятия этого неведомого демона, который НЕГАДАННО рухнул.

Были приведены аргументы, почему shell хуже, чем декларативное описание. Были приведены примеры функциональности, которую сложно корректно реализовать на shell. Вас они не убедили - ваше дело.

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

Смогут, в промежутках между падениями.

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

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

за всё надо платить. "Подводные камни" -- расплата за универсальность. Как только этот ваш systemd заматереет, у него будет подводных камней не меньше, а скорее больше.

Что касается базовой функциональности системы инициализации, то shell плохо подходит для её реализации из-за низкой скорости работы и функциональной примитивности (например, нет нормальных средств синхронизации).

скорость не имеет значения. Я что-то не припомню сервисов, которые быстро подымаются после падения. Какая-то синхронизация тоже не очень понятно зачем нужна.

По части скорости так вообще не аргумент — голая слака на bash-скриптах загружается с ssd тоже за секунду, как у Леннарта. Смысл?

только перезапускать постоянно падающие демоны.
Это реально проблема. Даже на домашней системе.

Android, Arch Linux, Windows

ну кто-бы сомневался…

[Hephaestus]

Это реально проблема. Даже на домашней системе.

Она работает лишь в очень простых ситуациях. Для обычного пользователя - её достаточно.

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

А вообще Ваши аргументы выглядят так, будто в этих ваших Linux'ах только и знай, поднимай упавшее да борись с тормозами. И помочь могут только медовые пряники systemd и его декларативные файлы. Без них вот прям никак.
Вот прям 20 с лишним лет только и ждали, когда придёт Леннарт и всех спасёт, а до этого и не работали вовсе.

[yars]

Неужели до сих пор встречается?

Когда-то было, но у меня сейчас в этом плане нет проблем.

[Hephaestus]

Это просто оголтелый и очень неумный, для инженерной темы, троллинг. =)

А вот это не троллинг?

Помогите нам стандартизировать Linux! Используйте новые конфигурационные файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!

Это и есть свидетельство тупикового пути. Если не орать на всех углах, призывая использовать новую Леннартову поделку, никто её и не заметит, ибо не нужна она. Ибо и без неё всё работает.
С systemd будет также как с Пульсой.

Доказательства ненужности Пульсы приводить надо?
Пожалуйста: Пульса пилилась до юзабельного состояния лет десять. Причем, автор её забросил уже несколько лет как. Брошена автором - это ли не свидетельство ненужности? Тем более, что и без неё всё работает. С systemd будет то же самое.

[drBatty]

Вот прям 20 с лишним лет только и ждали, когда придёт Леннарт и всех спасёт, а до этого и не работали вовсе.

просто некоторы тут не понимают, что по большому счёту

Код: Выделить всё

sh == systemd

если вы подумаете, то поймёте, что sh -- это тоже

1. такая программа на PureC, в которой можно объявлять декларации для запуска других программ на PureC.
2. анализировать код возврата этих программ на PureC(и действовать по обстоятельствам)
3. запускать программы не только последовательно, но параллельно, например как конвейер или как сопрограмму.

RedHat в очередной раз придумала NIH.

PS: да, можете начинать объяснять, какой я некомпетентный, и какие вы все умные, грамотные, и опытные. Мне не привыкать.

[drBatty]

Доказательства ненужности Пульсы приводить надо

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

Раздельная установка уровней громкости для разных программ[1].
Возможность смешивать потоки с разных звуковых плат.
Расширяемая модульная система с поддержкой динамически загружаемых библиотек
Совместимость со многими популярными аудиоприложениями.
Возможность работы с несколькими источниками и приёмниками звука.
Малая задержка и возможность её точного измерения[2][нет в источнике].
Использование технологии zero-copy, сберегающей машинное время.
Интерфейс командной строки с возможностью использования сценариев.
Демон, перенастраиваемый с помощью командной строки.
Встроенное преобразование аудиоформатов.
Синхронизация потоков воспроизведения.
Смешиваемые потоки могут иметь разные частотные характеристики.
Эффективный микшер, даже для звуковых плат без микшера, предотвращающий «монополизацию»/«кражу» звукового устройства отдельной программой.

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

[Bizdelnick]

Для обычного пользователя - её достаточно.

О! Может хоть ты, наконец, подскажешь мне, где можно почитать спецификацию обычного пользователя™? Очень надо для полноценного участия в холиварах, нигде найти не могу. :-(

[drBatty]

где можно почитать спецификацию обычного пользователя™? Очень надо для полноценного участия в холиварах, нигде найти не могу. :-(

не благодари

[Red Gremlin]

Смотрите сами: Давайте возьмем для простоты арифметики цифру 100Мб.

А почему не 100 килобайт? Или даже 100 байт? У меня нашлась ровно одна система, где /var/log/ в 100Мб поместилось, да и та сервер постгреса, десятки мегабайт логов которого не в /var/log хранятся. А для раздела на пару гигов 15% уже весьма хороший запас.

При таком раскладе распухающий лог займет 85Мб и после этого сервис упадет, потому что больше места нет

С чего он вдруг упадёт? journald при нехватке места для хранения начинает "забывать" наиболее старые записи. Этакая принудительная ротация для особо тупых админов.

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

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

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

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

[serzh-z]

спецификацию обычного пользователя™?

Мне кажется, что это ты тут выше писал про логи - намекал на то, что пользователи десктопов - это немного не те пользователи, ради которых стоит стараться упрощать процесс сопровождение системы. А настоящему одмину, вроде как, логи нужно читать, и обязательно чтобы не в непонятном бинарном формате, а в ASCII.

[Bizdelnick]

Мне кажется, что это ты тут выше писал про логи - намекал на то, что пользователи десктопов - это немного не те пользователи, ради которых стоит стараться упрощать процесс сопровождение системы. А настоящему одмину, вроде как, логи нужно читать, и обязательно чтобы не в непонятном бинарном формате, а в ASCII.

То есть обычные пользователи™ - это пользователи десктопов? Так я всё-таки обычный пользователь™, когда сижу за десктопом? Мне так часто пытались доказать, что это не так...

[Hephaestus]

А почему не 100 килобайт?

Я ж сказал, для простоты примера.
Не нравится цифра - можно взять 100Гб. Какая разница?
Суть в том, что заглючивший демон съест остатки дискового пространства. И резерв тут не поможет, ибо он тоже не бесконечный.

С чего он вдруг упадёт? journald при нехватке места для хранения начинает "забывать" наиболее старые записи. Этакая принудительная ротация для особо тупых админов.

Ого! То есть подчищает журналы по мере заполнения диска? Да ещё без спросу? Лихо!
Получается в описанной ситуации, заглючивший демон съел всё пространство, какое можно, journald для поддержания работосопосбности журналы подчистил...
При интенсивном заполнении можно уже к обеду лишиться утренних записей в журнале за тот же день. Здорово. Никаких следов. Очень полезная возможность.

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

Просто эта проблема не настолько частая, чтобы из-за неё городить автоматику, тем более, что автоматика в большинстве случаев не поможет.
Скажите, Вы всерьёз полагаете, что Леннарт первый за 30 лет существования UNIX, кого посетила идея автоматического перезапуска демонов?
И Вы уверены, что создателям UNIX не приходила эта идея?
Наверняка приходила. И сделали бы. Давно уже. Если бы не бритва Оккама.

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

На самом деле, Вы очень близки к истине.
С компьютерами люди практически разучились считать.
А с такими идеями как у Леннарта рискуют ещё и разучиться думать.
Но к счастью, этого не произойдет.
Ибо идеи, реализованные в systemd (как и любая автоматика) будут давать ложные срабатывания (как ни крути, а искусственного интеллекта там всё-таки нету).
А с учётом того, как много стараются в systemd запихнуть, этих ложных срабатываний будет немало.
Жаль только, что людям придется тратить время и силы на разгребание systemd'шных глюков, хотя эти ресурсы можно было бы потратить с большей пользой.

[serzh-z]

Скажите, Вы всерьёз полагаете, что Леннарт первый за 30 лет существования UNIX, кого посетила идея автоматического перезапуска демонов?

Я уже понял, что поттероненавистники ни разу не читатели, но всё же ещё раз упомяну: авторы systemd много написали на тему того, что идея systemd - не нова, inetd, xinetd и launchd давно и успешно используют тот же самый подход. systemd - это тот же launchd, но для Linux.

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

[eddy]

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

Батенька, зачем вы тут надрываетесь? Ну неужто вы не можете просто понять, что не нужна людям эта говнотень! Просто не нужна!
Никому нет желания учиться работать с новой системой инициализации и переписывать 100500 своих скриптов, если все прекрасно работает в старой!

Вот и все! systemd годится лишь для "хомячков", которые ставят дефолтную бубунту и даже внешнего оформления не меняют!

[Kopilov]

systemd годится лишь для "хомячков", которые ставят дефолтную бубунту

Когда появится по дефолту в Дебиане -- сгодится и для "бобриков", которые ставят дефолтный Дебиан

[serzh-z]

Батенька, зачем вы тут надрываетесь?

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

[Kopilov]

Ну увы.

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