Релиз systemd 212

у меня вообще дебиан стабле

пока системде не станет «протухло» и «говно мамонта» думаю не тыкать

системд не стабилен

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

То что он загружает систему это не говорит что все хорошо.

Но вам не кажется, что слишком много в него запихнули?

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

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

Угу. Ну а почему бы нет, если всё работает. Правда если что-то нужно будет установить, то всё равно придётся обновиться. Локальную репу я к сожалению «потерял» с винтом.

Но вам не кажется, что слишком много в него запихнули?

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

жду:

- systemd-fs

- systemd-wysiwyg-texteditor

- systemd-emacs

... etc :)

В journald добавлен режим перенаправления вывода на консоль, который теперь активирован по умолчанию для всех важных уведомлений;

Я правильно понял, что тепер к примеру

systemctl restart httpd

В sysvinit сотоварищи запихано в разы больше.

О как. Что там запихано кроме вызова штатных утилит?

- systemd-fs

Яростно плюсую. ОЧЕНЬ НЕХВАТАЕТ!

очередная версия «ненужно» для систем, активно принимающих в себя зонды. деньги Поттеринг управляет миром! Спасайся!

Что там запихано кроме вызова штатных утилит?

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

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

Ядро, на к-рое завязан systemd, в сумме с glibc занимает почти 100 мб. Т.ч. инитскрипты всё равно легче. ;)

и десяток-другой тысяч строк баш-кода

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

текстовыми конфигами вместо скриптов

Если бы.

Который, правда, умеет в несколько раз поболее

1. Custom actions.
2. Динамические зависимости (как в openrc).
3. Циклы и ветвления без врапперов на си/шелле.

Я жду.

А мне systemctl понравился, оставил, ЧЯДНТ?

Ядро, на к-рое завязан systemd

/etc/init.d# grep '/proc' * | wc -l
196

Вот такие мы в sysvinit на ядре не завязанные.

в сумме с glibc

Я пропустил и баши/грепы научились без либц обходиться?

инитскрипты всё равно легче

Инитскрипты без десятков бинарников бесполезны примерно целиком.

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

Открываю /etc/init.d/console-screen.sh и нахожу там:
/bin/run-parts
/usr/bin/consolechars
/usr/bin/charset
/usr/sbin/vcstime
/bin/uname
/bin/cut
/bin/fgconsole
/bin/grep
/bin/sed
/bin/kill
/usr/bin/dumpkeys
/usr/bin/setleds
/bin/pidof
Меня терзают смутные сомнения, что в несколько сотен строк на Си это немного не уложится.

Если бы

По ссылке какой-то альтернативно мыслящий. Конфиг не обязан полностью реализовывать синтаксически всю булеву алгебру.

1. Custom actions.

What do you mean?

2. Динамические зависимости (как в openrc)

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

3. Циклы и ветвления без врапперов на си/шелле

Жду «Циклы и ветвления без врапперов на си/шелле» в sysvinit.

Ядро, на к-рое завязан systemd, в сумме с glibc занимает почти 100 мб. Т.ч. инитскрипты всё равно легче. ;)

Упрлс?

Просто ему systemd — как красная тряпка для быка, при одном виде глаза наливаются кровью, копыта бьют землю и в голове остаётся лишь одна мысль «Убить! Убить! Убить!»

/proc

procfs есть много где, отличии от тех же cgroups.

Я пропустил и баши/грепы научились без либц обходиться?

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

Инитскрипты без десятков бинарников бесполезны примерно целиком.
Открываю /etc/init.d/console-screen.sh и нахожу там:

Я тебя огорчу, но systemd точно также запускает loadkeys, setfont etc., только делает это внутри сишной портянки. А зачем вообще дублировать чужую работу и заново писать то, что уже реализовано в готовых утилитах, для меня есть тайна великая.

Меня терзают смутные сомнения, что в несколько сотен строк на Си это немного не уложится.

Правильно, поэтому того же автоматического включения numlock в консоли во systemd-vconsole нет. БУ. ГА. ГА.

Конфиг не обязан

Но реализовывать почему-то приходится. Видать, даже врапперы не всегда спасают. Может гениальная идея «выбросить шелл-код из юнитов вообще и свести всё к простым ini-конфигам» была не такой уж гениальной? ;)

What do you mean?

Например, добавить действие save к сервисе iptables, чтобы по нему сохранять текущие правила (раньше в арче так и делалось, через /etc/rc.d/iptables save). В обычном скрипте такое реализуется элементарно, в openrc для этого есть спецаильная директива, а в systemd как?

Пример, когда это очень-очень нужно

Посмотри, как сделан сервис syslog-ng в openrc.

Жду «Циклы и ветвления без врапперов на си/шелле» в sysvinit.

Достаточно открыть любой инитскрипт…

Просто ему systemd — как красная тряпка для быка
redgremlin

Фанатикам повсюду мерещатся фанатики?

Упрлс?

Это не я спихнул в одну кучу инитскрипты, базовые утилиты и procfs. :)

Например, добавить действие save к сервисе iptables, чтобы по нему сохранять текущие правила (раньше в арче так и делалось, через /etc/rc.d/iptables save).

С каких пор сохранение правил ядерного фаерволла - это задача инита?

Оно не может actions ибо убого по дефолту. Цитирую:

Критика систем, ориентированных на зависимости

Недостатки

Не отражает «живую натуру» современного Linux Главная проблема состоит в том, что в таких случаях по-прежнему не признается динамичный характер современных Linux – систем. К примеру, если такой СИ необходимо запустить сервис базы данных MySQL, то она сначала запустит те сервисы, от которых зависит сервис MySQL. В данном случае это совершенно правильное решение. С другой стороны допустим, что пользователь захотел подключить к своему ноутбуку внешний монитор. Хотелось бы чтобы система в этом случае выдавала некий диалог с вопросом как ей поступить с этим внешним монитором. Такое здесь возможно только при наличии СИ «с хаками», так как стандартная СИ с учетом зависимостей никак не может узнать об изменении конфигурации оборудования. В случае с диалогом подключения монитора у вас могут быть следующие варианты:

∙ Ничего не делать.

∙ Иметь демона, опрашивающего систему на предмет появления новых устройств.

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

∙ Upstart запускает службы когда необходимые для этого условия будут выполнены: в файле конфигурации службы необходимо только указать условия ее запуска и ее исполняемый файл.

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

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

Взято из «Upstart Cookbook».

С каких пор сохранение правил ядерного фаерволла - это задача инита?

С тех, когда в этот самый инит встроили веб-сервер и генератор qr-кодов. ;)

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

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

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

Во-первых, я не прошу инит заниматься правилами фаерволла, я прошу добавить в формат юнитов возможность указывать свои действия помимо стандартных start/stop/restart/reload.

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

я прошу добавить в формат юнитов возможность указывать свои действия помимо стандартных start/stop/restart/reload.

Напиши юнит iptables-save и вызывай там что нужно. Проблемы?

sysvinit, к примеру, это вообще не нужно

Мыслишь в правильном направлении.

этим занимаются более высокоуровневые утилиты

Портянки на баше?

такие глобальные вещи, как парсинг юнитов и запуск/останов сервисов, делаются непосредственно в PID 1

И что? Нет, серьезно.

Напиши юнит iptables-save и вызывай там что нужно

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

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

Портянки на баше?

Ну можно и не на баше. :)

как парсинг юнитов
непосредственно в PID 1

И что? Нет, серьезно.

Ты правда не понимаешь?

Зачем делать сервис на разовую операцию?

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

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

В systemd у всех юнитов одинаковые команды, что прекрасно. А в твоих любимых инитах у одного скрипта есть save, а у другого - нет. Бардак и никакого единобразия.

Ты правда не понимаешь?

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

Давайте обсудим компилятор vs интерпретатор. Спор тот же.

В systemd у всех юнитов одинаковые команды, что прекрасно. А в твоих любимых инитах у одного скрипта есть save, а у другого - нет. Бардак и никакого единобразия.

Посмотрим, как ты запоешь, когда твоему юниту потребуется save.

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

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

Портянки на баше?

Чем портянка на Си, дёргающая 100500 внешних утилит, лучше портянки на баше, дергающей... OH SHI~~ Ничем не лучше. Внезапно.

А вот недостатки очевидны. Перечислить или сам догадаешься?

Не сервис, а юнит, разберись в матчасти для начала.

Дело бы вечером…

И встречный вопрос: на кой, делать дополнительный аргумент rc-скрипту для разовой операции?

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

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

Добавлять будет тот, кто пишет юнит. Разработчик/мейнтейнер/etc.

В systemd у всех юнитов одинаковые команды, что прекрасно. А в твоих любимых инитах у одного скрипта есть save, а у другого - нет.

systemctl reload gpm

Давай пример

Допустим, в парсере есть баг, приводящий к сегфолтам…

Допустим

щас он скажет, что проблема гипотетическая

Посмотрим, как ты запоешь, когда твоему юниту потребуется save.

Во-первых, я не вижу причин, по которым мне потребуется save, а во-вторых, проблема эта решаема.

Если бы мне было интересно твое мнение, я бы его обязательно спросил.

Перечисляй.

Во-первых, я не вижу

В том, что ты не видишь, нет ничего удивительного. Любители подменять общие решения частными - они все такие, не видящие. УМВР, ненужно и т.п.

во-вторых, проблема эта решаема.

Костылями? Патчами на системд? Тел ми моар, любитель некостыльного системд.

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

Допустим

Ну вот опять.

Да.

Деточка, посмотри выше по треду, ага?

Напиши юнит iptables-save

костылями

Ты с чем-то хочешь поспорить?

Неа, не хочу, зря ты так думаешь.

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

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

Это к чему сейчас вообще было?

Ну вот опять.

Binary, ты угадал. :)

Нет уж, поуговаривайте меня.

Это к чему сейчас вообще было?

Объясняю еще раз на пальцах: вот есть у тебя две системы, одна с systemd, другая - с sysvinit. В первой есть юнит iptables.service, у которого нет аргумента save, у другой есть rc-скрипт iptables, у которого тоже нет аргумента save. А вот теперь он лично тебе понадобился. Твои действия?

Твои действия?

Проверяю, есть ли в systemd поддержка custom actions
if (( $? )); then
  Связываюсь с мейнтейнером юнита
  Прошу добавить что-то вроде Exec['save']=iptables-save bla-bla-bla
else
  Сношу systemd
  Ставлю initscripts-fork
  Продолжаю ругать systemd
fi

Удачи.

Удачи.

Спасибо, но с моим форком она мне не особо нужна. :)

Это было несложно.