LINUX.ORG.RU

systemd 249

 , , , ,


0

1

Новый релиз системного менеджера GNU/Linux — systemd (лицензия GPL-v2+):

  • возможность явного или автоматического выбора из нескольких root разделов в образе диска с помощью параметра --image= в systemd-nspawn, systemd-dissect и других утилитах, работающих с образами дисков

  • новые опциональные параметры IMAGE_VERSION и IMAGE_ID в файле /etc/os-release

  • поддержка build-id и .note.package из ELF в systemd-coredump позволяет явным образом соотнести дамп памяти с конкретным пакетом, из которого был установлен соответствующий бинарник

  • поддержка UUID для событий udev, которая позволяет отслеживать конкретное событие в явном виде

  • документирован сетевой протокол Journal

  • домен «home.arpa» официально добавлен в качестве домена для локальных сетей согласно RFC 8375

  • флаг «grow-file-system» добавлен к спецификации Discoverable Partition

  • поддержка JSON с помощью интерфейса DBus и параметра командной строки в systemd-hostnamed и systemd-networkd. В дальнейшей её планируется распространить на все компоненты systemd

  • автоматическое добавление хэшей паролей в shadow для пользователей systemd-homed

  • поддержка добавления пользователей и групп с помощью конфигурационных файлов в формате JSON в /etc/userdb/, /run/userdb/, /run/host/userdb/ и /usr/lib/userdb/

  • расширение механизма зависимостей с помощью неконфигурируемых автоматических обратных зависимостей (OnSuccessOf для OnSuccess, UpheldBy для Upholds, OnFailureOf для OnFailure и т. п.) для упрощения отслеживания и настройки зависимостей между юнитами

  • по многочисленным просьбам анонимусов с LOR была документирована архитектура systemd

И множество других изменений, исправлений и улучшений.

>>> Подробности

★★★★

Проверено: alpha ()

Ответ на: комментарий от Csandriel_x64

то ЧЕМ и КАК и ЧТО ты будешь исправлять?

emergency shell, debug shell.

А читающему значит не дано понимать зависимости?

Нет, он будет вынужден открывать документацию и читать ее, и слава б-гу, если там будет полная и корректная информация.

В моем случае, о котором я упомянул (встречался в сюзе), понадобилось просто исправить fstab

При проблемах в fstab ты загружаешься в emergency shell и смотришь journalctl, где видишь проблемы с fstab.

которые можешь решить и ты

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

Видишь – ты просто посмотрел в скрипт и уже видишь даже потенциальную проблему. Значит считай она решена, буде она иметь место.

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

А что с systemd?

А там этой проблемы нет и не будет by design.

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

Зачем? Где здесь тот самый KISS? То, как результаты проверки обрабатываются в материнском процессе, отлично видно в портянке сверху, где коды возврата просто игнорируются.

Siborgium ★★★ ()
Ответ на: комментарий от Siborgium

При проблемах в fstab ты загружаешься в emergency shell

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

Csandriel_x64 ()
Ответ на: комментарий от Reset

У меня есть сервис, в котором логирование сделано максимально просто и топорно – вызовом функции printf

А зачем? Чтобы в очередной раз героически решать проблемы, которые ты сам себе не менее героически создал? Или потому, что его писал детсадовец, который про системы логгирования в unix ни сном ни духом?

anonymous ()
Ответ на: комментарий от Siborgium

где коды возврата просто игнорируются. очевидно потому, что дочерние скрипты в состоянии выматериться юзеру в консоль сами. By-design

Речь о том, что у systemd нет ни одного реального «преимущества». Потому что цветной синтаксис в журнале это не преимущество. И графон с зависимостями это не преимущество – это вообще не профильные абилки; таким вообще должны заниматься отдельные тулзы: и расцветкой журнала – кому она нужна, – и рисованием зависимостей – если кого этот графон интересует. И между такими тулзами должна быть конкуренция, тогда в дистры пойдут лучшие из лучших тулз.

Systemd – повторюсь – предлагает гору всякого разного с палками, которая мало кому нужна, но есть у всех (кто ставит себе этого трояна). Мне это напоминает про фотошоп современный, который больше иных ОСей. Ибо он заточен на дэбилов. В нем включены все возможные «волшебные кнопки», на каждый случай жизни, которые нужны 0.001% проценту пользователей а втыкают их всем и каждому.

Думаю, я не доживу до дней когда увижу слаку такой. На мой век хватит и аминь.

Csandriel_x64 ()
Ответ на: комментарий от Csandriel_x64

Ибо простота равна надежности, при всех прочих равных.

Все про «надежность» уже стало понятно, можно не продолжать.

Так что любая программа таки ДОЛЖНА быть предельно простой.

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

А значит «тупому админу» не дано знать зависимости сервиса, если уж он берется писать скрипт его запуска?

Админу дано, а вот системе не дано. Юниты дают эту информацию системе.

Я так понимаю, systemd имеет помимо прочих фишек презупцию того, что пользователь и админ – идиоты

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

Если тебя устраивает такое отношение со стороны разработчиков systemd и их забота о том, чтобы ты себе пальцик не порезал…

Ну вот, переходишь на личности и пытаешься взять на «слабо». Может, все же по теме будем вести обсуждение?

Касательно тезиса: не хочу резать пальцы, хочу работающую и расширяемую систему инициализации.

Siborgium ★★★ ()
Ответ на: комментарий от anonymous

А зачем нет, особенно, если это решает все проблемы?

Во-вторых, сейчас в клауде так гораздо удобнее.

Я вот вообще тоже склоняюсь к тому, чтобы не использовать spdlog. fmt::print одного более чем достаточно.

anonymous ()
Ответ на: комментарий от Siborgium

Все про «надежность» уже стало понятно, можно не продолжать.

Понятно что тебе нечего в ответ булькнуть и базовая логика неумолима?

а вот системе не дано.

какой системе? systemd? Я разве не только что говорил, что systemd порождает сам те самые проблемы которые «решает»?

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

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

Может, все же по теме будем вести обсуждение?

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

Аминь.

Csandriel_x64 ()
Ответ на: комментарий от Csandriel_x64

Речь о том, что у systemd нет ни одного реального «преимущества».

Я уже писал, и напишу еще раз. Зависимости между сервисами передаются системе, которая на основе этих зависимостей строит граф задач, который затем исполняет. Не ты этот граф строишь, а система. Не ты рыскаешь по манам и в интернете в поисках информации, выписываешь зависимости и думаешь, в какой последовательности тебе что запустить, fork’аешь и ожидаешь, и ловишь баги в свой лапше, а система, которая уже отлажена. Если в ней что-то не так, то это на 99.9% проблемы некорректно написанного юнита, и эти проблемы легко отловить, потому что доступно большое количество информации и инструментов.

Мне это напоминает про фотошоп современный, который больше иных ОСей. Ибо он заточен на дэбилов. В нем включены все возможные «волшебные кнопки», на каждый случай жизни, которые нужны 0.001% проценту пользователей а втыкают их всем и каждому.

А ты фотошопом-то пользовался? Я вот пользовался, и с уверенностью скажу, что 3/4 кнопок в основном окне программы очень даже активно используются.

Siborgium ★★★ ()
Ответ на: комментарий от Csandriel_x64

Понятно что тебе нечего в ответ булькнуть и базовая логика неумолима?

Ты сам скинул кривую портянку, и теперь меня упрекаешь в отсутствии аргументов?

какой системе?

Твоему материнскому процессу со скриптом.

Поверь, в дистрах без systemd такой сложности нет.

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

Siborgium ★★★ ()
Ответ на: комментарий от Siborgium

Я уже писал, и напишу еще раз

Ок, ценю твердолобость.

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

Тоесть ты благодарен systemd что он сам решает большую часть тех проблем что создал, а не взвалил все из них на тебя?

А ты фотошопом-то пользовался?

Ага. Я остановился и стоял на версии 7.0 когда актуальной была уже версия cs3, тоесть 13. Это потому, что ничего принципиально нового с 7-ки в нем не появилось. Одни волшебные кнопки для инвалидов – до сих пор спавнятся как плесень. Вот почему я уважаю GIMP и linux-way – потому что лет десять работал с фотошопом профессионально, и видел, к чему и как он пришел. Вообще виндой весьма сыт, и не понимаю тех, кто с энтузиазмом воспринимает мутацию линукса в винду, прежде всего под влиянием трояна тысячелетия, под названием systemd

Csandriel_x64 ()
Ответ на: комментарий от Siborgium

emergency shell, debug shell

Дооооо… Ты сам-то пробовал? Видел, что твой любимый journalctl тебе напишет что-то вроде «ошибка монтирования корневого раздела»? И всё лишь потому, что /etc/fstab «испортился». Совсем. Весь. Но догадываться ты об этом будешь сам, предварительно побаловавшись с e2fsck и прочими инструментами.

anonymous ()
Ответ на: комментарий от anonymous

И какие проблемы это решает: Централизованное хранилище логов? Хранение на другом узле? Оповещение заинтересованных лиц в мессенджер/SMS? Как простой вывод на экран это всё делает, расскажи.

anonymous ()
Ответ на: комментарий от Reset

Затем, что сделать перенаправление в файл и не изобретать велосипеды это и есть unix-way, в который не умеют все эти допотопные системы инициализации

Даааа…. Ну, как дойдёте до задач, которые давным-давно успешно решал банальный syslog и надумаете изобретать очередной journalctl v.1000478634785 - напишите. Может я к тому времени ещё буду недостаточно стар, чтобы понять, в какой файл надо перенаправить вывод stdout чтобы он переслался в SMS, например.

anonymous ()
Ответ на: комментарий от Reset

Т.е. надо написать ещё одно приложение, которое будет мониторить stdout,stderr этого детсадовского поделия (которое с какого-то перепугу стало МОИМ, хотя в прошлом посте работало У ТЕБЯ) чтобы решить проблемы, которые решили лет 40 назад путём создания стандартизованной системы логгирования только потому, что этот самый детсадовец про них ничего не знал?

Эксперты systemd в своём репертуаре…

anonymous ()
Ответ на: комментарий от Reset

Ни секунды не сомневаюсь, что именно так тебе и объяснил создатель этой самой детсадовской программы, потому что единственное, что он мог бы сделать - завернуть вообще всё логгирование в SMS и принести счёт от оператора сотовой связи на сумму с кучей нулей. А в приоритеты, фильтрацию и разные точки назначения в зависимости от параметров сообщения он сможет лет через 15 в лучшем случае.

anonymous ()
Ответ на: комментарий от anonymous

«ошибка монтирования корневого раздела»

При такой ошибке fstab – одно из наиболее очевидных мест для проверки.

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

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

Siborgium ★★★ ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от Siborgium

Ну вот. Такие своими кривыми ручками напонаправляют файлы, а потом жалуются, что ничего не работает и непонятно почему.

Некоторые разработчики оградили от таких убогих утилитами типа sudoedit и похожая для крона. Но не везде применимо. Хотя systemd, надеюсь, тоже неспроста имеет отдельный daemon-reload.

anonymous ()
Ответ на: комментарий от Siborgium

Пусть так, всё равно понять что такое syslog, как оно работает и причём тут unix-way экспертам systemd не дано….

Вы мне ответьте, почему вы printf используете? Ведь это же не unix-way’но. Надо запилить собственную функцию вывода.

anonymous ()
Ответ на: комментарий от Siborgium

Как баловавшийся с e2fsck сообщаю: диагностика e2fsck довольно однозначно укажет, что проблема не в фс

Да ты что?! Правда чтоли? А время, которое ты потратил за запуск и анализ выхлопа e2fsck тебе кто вернёт? Поттеринг?

Так как проблема в монтировании, то логично проверить место, в котором я указываю, как монтировать фс

С чего вдруг? Может у тебя /sbin/mount окочурился?

anonymous ()
Ответ на: комментарий от anonymous

Пусть так, всё равно понять что такое syslog, как оно работает и причём тут unix-way экспертам systemd не дано….

Какое отношение к логу в приложении имеет systemd?

Вы мне ответьте, почему вы printf используете? Ведь это же не unix-way’но.

Очень даже unix-way’но.

Siborgium ★★★ ()
Ответ на: комментарий от anonymous

А время, которое ты потратил за запуск и анализ выхлопа

10 минут? Жаль, конечно, но и fstab не каждый день наворачивается.

С чего вдруг? Может у тебя /sbin/mount окочурился?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab. Это допустимо, но вариант с fstab многократно вероятнее.

Siborgium ★★★ ()
Ответ на: комментарий от anonymous

Я - про syslog и даже, чёрт с ним, systemd journal.

В первом случае, в чем принципиальное отличие? Сидит такой же демон, который читает из дескриптора и куда-то складывает.

Он есть, умеет, отлажен, работает. Уже есть. Уже работает. У него только один фатальный недостаток…

Во втором случае как ты все перечисленное реализовал?

А зачем у меня это спрашивать? Это у @Reset такая гениальная система логгирования, которая printf’ом логи пишет непонятно куда. У него и спрашивай, какими костылями он это огородил.

anonymous ()
Ответ на: комментарий от Siborgium

Какое отношение к логу в приложении имеет systemd?

Эксперты systemd такие эксперты, даже самого systemd не знают…

man systemd-journald.service

Очень даже unix-way’но

Уже существующий printf - unix-way’но, уже существующая система логгирования - не unix-way’но. Трудно быть шизофреником, понимаю.

anonymous ()
Ответ на: комментарий от Siborgium

10 минут? Жаль, конечно, но и fstab не каждый день наворачивается.

Я не спрашивал, жаль тебе или нет, я спрашивал, кто тебе их вернёт. Так кто?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab

Правильно, они вносятся прямыми. zypper dist-upgrade например.

anonymous ()
Ответ на: комментарий от anonymous

man systemd-journald.service

Еще раз, какое отношение журнал systemd имеет к логу в приложении? Почему приложение должно завязываться на journald или syslog? На это вменяемые ответы будут?

Siborgium ★★★ ()
Ответ на: комментарий от anonymous

Я не спрашивал, жаль тебе или нет, я спрашивал, кто тебе их вернёт. Так кто?

Кто тебе часы переписывания портянок вернет, клоун?

Правильно, они вносятся прямыми. zypper dist-upgrade например.

Вот и славно, что прямыми. Тем больше уверенности в том, что смотреть нужно fstab.

Siborgium ★★★ ()
Ответ на: комментарий от Siborgium

Еще раз, какое отношение журнал systemd имеет к логу в приложении?

Приложение может в него писать.

Почему приложение должно завязываться на journald или syslog?

Потому же, почему оно завязывается на printf.

anonymous ()
Ответ на: комментарий от Siborgium

Кто тебе часы переписывания портянок вернет, клоун?

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

Тем больше уверенности в том, что смотреть нужно fstab

С какого счастья при обновлении БИНАРНИКОВ надо смотреть текстовый КОНФИГ? Который: а) при предыдущих обновлениях не менялся никогда, б) если какие-то конфиги переписываются - zypper плюнет в консоль минимум warning в) из сообщений «божественного» journalctl ровно НИКАК не следует, что с fstab хоть какие-то проблемы имеются.

anonymous ()
Ответ на: комментарий от anonymous

Потому же, почему оно завязывается на printf.

Невозможно «завязаться» на printf, реализация этой функции есть везде – в отличие от syslog/journald и др.

С какого счастья

Попробуй почитать сообщения, на которые ты отвечаешь.

Siborgium ★★★ ()
Ответ на: комментарий от Siborgium

Ну вот такие мусье наприбивают наглухоря гвоздями к какой-то системе, а потом жалуются, что что-то теперь не как раньше, все надо заново учить/делать…

И я понимаю был бы какой-нибудь структурированный логгер, от которого есть какой-то профит при анализе логов (да, тот же journald или wpp/etl на оффтопике). Но формат сислога ж достаточно убог.

Или вот этот костыль с sighup…

anonymous ()
Ответ на: комментарий от Siborgium

Невозможно «завязаться» на printf, реализация этой функции есть везде

4.2. BASIC, Pascal, C#, Python - нету.

Попробуй почитать сообщения, на которые ты отвечаешь

Понятно, почему при изменении бинарников надо смотреть текстовый конфиг - известно только Поттерингу и его почитателям. Какие ещё у вас есть откровения? Когда комп вырубается по kernel panic: out of memory надо проверять вентилятор?

anonymous ()
Ответ на: комментарий от anonymous

И я понимаю был бы какой-нибудь структурированный логгер

Это printf «структурированный логгер» чтоли?

Но формат сислога ж достаточно убог

В journal используется классификация уровней ошибок:

0 — EMERG (система неработоспособна);
1 — ALERT (требуется немедленное вмешательство);
2 — CRIT (критическое состояние);
3 — ERR (ошибка);
4 — WARNING (предупреждение);
5 — NOTICE (всё нормально, но следует обратить внимание);
6 — INFO (информационное сообщение);
7 — DEBUG (отложенная печать).

Уровни логгирования syslog в порядке уменьшения важности: emerg - Система в панике. Сообщения немедленно выводятся на все активные терминалы. Продолжение работы невозможно. alert - Система может продолжить работу, но эту ошибку следует устранить немедленно. crit - Это критические ошибки, такие как проблемы с аппаратным обеспечением или серьезные нарушения работы программного обеспечения. err - Разнообразные ошибки. Такие ошибки должны быть устранены, но они не разрушат вашу систему. warning - Предупреждения. notice - Общая информация которая должна быть записана, если она вам нужна, вероятно она не потребует вашей реакции. info - Различная системная информация. debug - Отладочные сообщения могут содержать всю информацию которую счел необходимым вывести ее разработчик для отладки кода. none - Специальный уровень означающий - <ничего не записывать в данной категории>.

Какой стройный структурированный journal! И какой убогий syslog!

Эксперты systemd прям эксперты…

anonymous ()
Ответ на: комментарий от anonymous

Это у @Reset такая гениальная система логгирования, которая printf’ом логи пишет непонятно куда.

Приложению не положено знать куда она оно пишет свои сообщения. Разгребать это – ответственность других слоев. Всё по Unix Way. У меня в итоге все попадает в «хадуп»-like систему и можно «грепать» это с помощью обычного sql.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Решил клоуна включить?

Зачем мне его включать? Ты и так здесь.

Есть другие стандартные функции для печати сообщений в стандартные потоки

Чего? Какие «другие»? Было сказано однозначно: «реализация этой функции есть везде». К тому же в том же самом C# Console.Write[Line] - это НЕформатированный вывод, а printf - форматированный. Эксперты systemd, вы вообще хоть что-то знаете?

anonymous ()
Ответ на: комментарий от Reset

Приложению не положено знать куда она оно пишет свои сообщения

И именно поэтому у него есть stdout и stderr. А в сокет надо писать почему-то через send, а не через printf. Не, приложению совершенно точно не положено знать, куда оно пишет… «Когда вы говорите, Иван Васильевич, впечатление такое, что вы бредите»(с)

anonymous ()
Ответ на: комментарий от anonymous

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

Клоун, ты даже не стараешься.

Так как проблема в монтировании, то логично проверить место, в котором я указываю, как монтировать фс

С чего вдруг? Может у тебя /sbin/mount окочурился?

Правки в /sbin/mount кривыми ручками не вносятся, в отличие от fstab. Это допустимо, но вариант с fstab многократно вероятнее.

Правильно, они вносятся прямыми. zypper dist-upgrade например.

Вот и славно, что прямыми. Тем больше уверенности в том, что смотреть нужно fstab.

С какого счастья при обновлении БИНАРНИКОВ надо смотреть текстовый КОНФИГ? Который: а) при предыдущих обновлениях не менялся никогда, б) если какие-то конфиги переписываются - zypper плюнет в консоль минимум warning в) из сообщений «божественного» journalctl ровно НИКАК не следует, что с fstab хоть какие-то проблемы имеются.

Siborgium ★★★ ()
Ответ на: комментарий от Siborgium

Т.е. ты настолько безмозглый, что даже не можешь внятно объяснить, почему надо смотреть в конфиг, хотя ДВЕ программы, которые работают с ним, ничего про это не сказали, но я клоун? Это работа с systemd так мозг разжижает? Или ты предавался половым утехам с Поттерингом и он тебя заразил чем-то?

anonymous ()
Ответ на: комментарий от thunar

Клятiй redhat ломает наш зоопарк несовместимости!!111ОДИНОДИНОДИН

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

zabbal ★★★★ ()

Вот сколько читаю комментарии, не могу никак понять, почему противники системд расписываю целые аргументированные портянки, а вот любители системд ограничиваются простым и кратким «вы просто ничего не понимаете, идиоты»?

anonymous ()