LINUX.ORG.RU

Релиз systemd 190

 


0

0

Леннарт Поттеринг рад представить очередной релиз загрузочного менеджера systemd.

Новшества:

  • Всякое изменение статуса юнита заносится в журнал и доступно для просмотра по команде «systemctl status».
  • ConditionPathIsMountPoint= теперь может правильно определять точки, смонтированные через bind.
  • Отныне по умолчанию монтируются cgroup-контроллеры cpu, cpuacct и cpuset, а также контроллеры net_cls и net_prio.
  • Контейнеры nspawn теперь имеют виртуализированный загрузочный ID: /proc/sys/kernel/random/boot_id монтируется со случайным ID при инициализации контейнера.
  • Новый режим вывода «json-pretty», при котором блоки JSON для более удобного восприятия оформляются с отступами по одному объекту на строку.
  • Удалены все явные вызовы sync() из кода выключения системы, так как ядро само использует эти вызовы при reboot().
  • Добавлена поддержка виртуального reboot() в контейнерах, поддерживаемого новыми ядрами.
  • journalctl по умолчанию показывает локальный лог. Для просмотра удалённых логов следует использовать ключ --merge (-m).
  • Для libsystemd-journal создан вызов sd_journal_get_usage() для определения текущего использования диска всеми файлами журнала. Опция доступна через команду «journalctl --disk-usage».
  • journald получил в journald.conf новую опцию SplitMode= для разбиения конфигурационного файла на части.
  • Новое условие ConditionFileNotEmpty= для проверки состояния файлов.
  • Добавлены биндинги Python для работы с журналом (пока реализованы частично). Официально будет поддерживаться только Python, но сторонние разработчики могут добавить биндинги к другим языкам (например, уже существуют биндинги Lua и PHP).
  • journald теперь предупреждает о невозможности доставки сообщения демону логирования при занятом сокете.
  • journald больше не изменяет /etc/localtime.
  • Теперь logind всегда резервирует один виртуальный терминал (по умолчанию — VT6) для текстового входа.
  • udev автоматически информирует ядерную подсистему btrfs на предмет доступных компонентов btrfs RAID.
  • Ограничение RLIMIT_NOFILE для PID 1 (но не его потомков!) повышено до 64 тысяч. Это сделано для возможности прослушивания большего количества сокетов.
  • При попытке монтирования журнала поверх непустого каталога администратор получает извещение.
  • Для юнит-файлов добавлена поддержка макроподстановок с именем хоста (%H), идентификатором машины (%m) и идентификатором загрузки (%b).
  • systemd теперь всегда конфигурирует часовой пояс для ядра при загрузке. timedated делает то же при изменении /etc/localtime.
  • Обновлена логика logind.

Скачать архив

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



Проверено: Shaman007 ()
Последнее исправление: Silent (всего исправлений: 1)

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

Мне интересно, вот если у меня на openrc не запустится dbus, всё равно можно будет загрузиться до терминала и исправить проблему. А как systemd будет работать при незапустившемся dbus, если он на него повязан?

Kindly_Cat
() автор топика
Ответ на: комментарий от vasily_pupkin

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

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

Я вот поинт с исправлением проблем из недогруженного режима не совсем понимаю. Зачем страдать? Ребутнуть тачку с init=/bin/bash, и все дела.

В любом случае, есть isolate, в который вываливаются если что-то поломалось. Критерий «что-то поломалось» в принципе, определяемый

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

Я вот поинт с исправлением проблем из недогруженного режима не совсем понимаю. Зачем страдать? Ребутнуть тачку с init=/bin/bash, и все дела.

Зачем ребутить, если система догрузилась до терминала?

В любом случае, есть isolate, в который вываливаются если что-то поломалось

Значит, всё верно: при крахе dbus валится весь systemd целиком? Эпичненько.

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

Ну что значит - крахе? Вот щас я его убил с kill -9. Все живо. Или ты про крах - когда его нет/он поломан/принципиально не работает?

Убей щас у себя dbus с -9, скажи что будет

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

ты вот лучше скажи — что через юдев делается такого полезного для сервера?

Делить операционки на десктопные и серверные это подход мелкомягких. Не хочешь юдев, оставайся на ядре 2.4.

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

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

imul ★★★★★
()
Ответ на: комментарий от no-dashi

Последовательность инициализации однотипных устройств определяется положением устройств в слотах.

Для эзернетов это уже не так

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

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

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

Администратор и утилиты работают не с тем, что ядро наопределяло, а с тем, что udev насоздавал и напереименовал.

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

Администратор и утилиты работают не с тем, что ядро наопределяло, а с тем, что udev насоздавал и напереименовал.

Я знаю. Но ты ответил на пост из треда обсуждения «а что было бы без udev».

tailgunner ★★★★★
()

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

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

stupid-mode: что делает systemd при падении dbus, умеет ли он рестартнуть его?

even-more-stupid-mode: Что делает systemd при падении systemd? Умеет ли он рестартануть самого себя?

anonymous
()

Весь линукс построен так что даже(!) когда что-то не работает - это можно ЛЕГКО найти и пофиксить(возможно уже не так легко). Все что делается - делается однотипно, просто и прозрачно. Это и есть UNIX-way. Если ему не следовать получим винду.

Комбайнам в линуксе не место.

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

что_угодно точно так же ломает и инитскрипты

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

«не читал, но осуждаю».

Читал-читал. Только не помню, что написано в пятом по счёту абзаце второй главы. А так читал… :)

ведь вы априори не можете ошибаться

Дык, если ты не видишь разницы между батниками и башем. В следующий раз ты, видимо, поставишь в один ряд Си и Жабу.

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

поставил по мануалу, работает без проблем, субъективно загрузка стала % на 15-20 быстрее

loki_ ★★
()

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

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

jackill ★★★★★
()

Сколько страниц тревоги и метаний!
Безмятежно смотрю я на сабж, ибо мои компы благословлены Слакой.

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

Так и не нужно полноценное. Лямбды, механизм коллбеков и некоторые другие плюшки, мощные макросы на уровне языка(а не сбоку прилепленные), ещё пару плюшек из мира FP. Асинхронность выполнения кода, в декларативном стиле тоже желательна. Для низкоуровневого заменителья ассемблера нет смысла реализовывать полностью FP. Просто некоторые плюшки, которые есть в том же JS перенести в нечто вроде C, сделать язык простым и компактным.

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

Значит, у вас не установлен syslog. Поттеринг писал что systemd сам определяет наличие syslog и только обнаружив его, начинает делиться с ним информацией:)

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

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

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

Где и от кого вы слышали фразу «переходите на systemd или обходитесь без udev»? Не на лоре от местных аналитиков? Поттеринг такого не говорил, я на его ленту Google+ подписан, в блоге его статьи читал - нигде такого не встречал.

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

Ах, вам надо еще и письменное подтверждение да еще и на личную почту? Три раза по «ха-ха».

Я думаю, что с вас достаточно будет и решения о слиянии кодовой базы udev и systemd http://permalink.gmane.org/gmane.linux.hotplug.devel/17392 Ну и до кучи решения майнтейнеров арча не распространять udev в виде отдельного приложения http://www.archlinux.org/news/systemd-tools-replaces-udev/

Как говорится sapienti sat. Но если вам и этого мало, то попробуйте скомпильнуть допустим thunar с поддержкой udev и без поддержки systemd. Я думаю, что это будет не такой гладкий процесс как вы, быть может, себе представляете.

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

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

Лямбды, механизм коллбеков

Это и так есть в Си и С++. Передавать указатели на функции и делать им typedef (всё с проверкой типов) я даже не знаю когда было нельзя. Лямбды сами по себе не представляют интереса - почти любые (такие как в С++11, например) из них переписываются как локальные функции в контексте top-level функций (как nested функции GCC), а те переписываются как глобальные функции с явной передачей замыкаемых переменных и значений. Основная сложность возникает при попытке вернуть замыкающую функцию из другой функции - ситуация полностью аналогична возвращению malloc-нутой памяти из функции в Си или работе конструктора вместе с new в C++, только вместо данных в той памяти будет код замыкания (пусть и статически генерированный), возникает ссылка на кучу и с ней нужно что-то делать - наложить условие уникальности или ввести для неё подсчёт пользователей (ссылок), первое сильно ограничивает аппликативную выразительность функций, а второе как бы не комильфо. В ФП языках и динамические данные и замыкания (код) что выходят из функций собирает GC с поколениями оптимизированный под конкретную VM.

Но в С++11 обещают замыкания, так что что-то вроде

template <typename A, typename B, typename C>
std::function<C(A)> compose(std::function<C(B)> f, std::function<B(A)> g) {
    return [=](A a) { return f(g(a)); };
}

должно работать, теоретически.

мощные макросы на уровне языка

Ну макросы это вообще другая степь.

и некоторые другие плюшки

ещё пару плюшек из мира FP

Например?

Асинхронность выполнения кода, в декларативном стиле тоже желательна.

Детерминированный параллелизм для Си в Intel пилили (Cilk). Для недетерминированной конкурентости - разные библиотеки MQ, треды и корутины, а на уровне языка более менее системного я такое только в Go видел, но там тоже GC.

Просто некоторые плюшки, которые есть в том же JS перенести в нечто вроде C, сделать язык простым и компактным.

Scheme, SML и OCaml (хотя в нём боксинг)? У них есть компиляторы via-c которые для определённых подмножеств (идиоматически близких к си) этих языков дают результат сравнимый с тем что дают компиляторы самого си. Но при активном использовании ФП и динамических структур данных уже будет дольше работать GC.

Ну и разные экспериментальные вещи ещё есть, вроде Cyclone.

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

а второе как бы не комильфо

Есть еще вариант из карманов Купертино, на тему управления очередями содержащими блоки кода на уровне ОС. Хотя лично мое имхо, что это тоже не слишком красивый вариант.

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

Поттеринг такого не говорил, я на его ленту Google+ подписан, в блоге его статьи читал - нигде такого не встречал.

Тебе может напомнить про судьбу патча, позволяющего собрать udev без systemd? На, почитай на досуге \url{http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg05287.html}

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

На Gentoo сидите? Тогда понятно почему вам не по душе systemd. Он с философией gentoo не очень хорошо вяжется. С точки зрения гентушника systemd огромное и ненужное нечто. Но в том же Debian или Arch и так много лишнего. Одной мелочью больше, одной меньше. Ещё пару зависимостей... Это всё мелочи.

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

Если из Go выпилить сборку мусора, интересный язык получится. Или хотя-бы сделать возможность писать код со сборкой, и без сборки по выбору программиста. А Cyclone интересный ЯП, про который я ничего не знал. Спасибо, что подсказали что есть такой ЯП.

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

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

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

My recommendation for distros who want udev without the rest of systemd is to build systemd normally and just pick the files you are interested in from «make install». (And besides that, I am pretty sure you probably want to pick at least tmpfiles in addition to udev from the build tree).

Вот г@нд()н! Благослови его Господь...

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

С точки зрения гентушника systemd огромное и ненужное нечто. Но в том же Debian или Arch и так много лишнего. Одной мелочью больше, одной меньше. Ещё пару зависимостей... Это всё мелочи.

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

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

Уважаемый, а может хватит отрывать мои слова от контекста, а? Я пишу что «архитектура слаба и Поттеринг плохой программист», а вы в ответ: «Значит проблемма не в архитектуре как таковой. Дело в репутации Поттеринга.» Я пишу, что udev самостоятельно, без systemd, не дает собирать приложения с его поддержкой". Вы в ответ: «На Gentoo сидите? Тогда понятно почему вам не по душе systemd»

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

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

А udev пора пилить (даже не форкать) свой. Возможно будет хорошим вариантом «ядро на си, бизнес-логика (правила и кастомные скрипты) на питоне»

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

Ого, на питоне... Скрипты для чего-то на замену udev. Жестоко. Вы о том, сколько такой велосипед грузится будет, и ресурсов системных потреблять даже не подумали. А ещё считаете Поттеринга плохим программистом. Да за python руки нужно отрывать... Хотите чего-то лёгкого - только lua. Но зачем нужна логика на скриптовом ЯП, когда есть этот недоязык bash? Для такой «продвинутой» логике даже старика sh хватит, без плюшек bash или zsh.

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

Да и городить кучу велосипедов, LFS юзать - это как-то неправильно. Gentoo никогда не перейдёт на systemd, тоже самое можно сказать про Slackware Linux. Патрик скорее примет постриг, чем засунет в свой дистрибутив такую новомодную штуку как systemd. А когда он спохватится, и решит всё-таки её пропихнуть в дистр(лет через 10), её уже не будет. Будет что-то новое, что вызовет резонное недоверие у Патрика, и всё начнётся заново.

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

То есть ты хочешь сказать, что у тебя в make.conf USE=-systemd и оно у тебя тянется по зависимостям?

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

Все нормально на генте. хоть с systemd, хоть без него. Кончай балаболить о том, в чем не разбираешься.

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

Gentoo никогда не перейдёт на systemd

Говорить «Gentoo перейдёт/не перейдёт на то-то и то-то» - абсурдно. Переходит не гента, а её конечные пользователи.

Kindly_Cat
() автор топика
Ответ на: комментарий от lucentcode

Портируют systemd на фряху и хард.

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

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

Нет конечно.

Сколько помню (детали мог уже подзабыть) было так: я собирал thunar с поддержкой udev. udev по зависимостям вытягивал udisk, а он, в свою очередь, собирался двумя возможными путями. Один путь с поддержкой systemd, второй - без. Первый собрался просто «на ура», второй - через дичайший геморрой и игру с нестабильными версиями polkit и т. д. и т. п.

k0valenk0_igor ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.