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)
Ответ на: комментарий от tailgunner

systemd - это не NIH, это обширный и хорошо поддержанный Redhat проект

поддержанный, епрст! да пусть rh хоть на каждую строчку кода systemd наймет по 1 работнику саппорта — это все равно будет хуже, чем иметь набор простых и понятных каждому демонов

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

systemd надо порезать* на init, udev, *inetd, логгер, stated (это такая хрень которая хранит состояние и че-то делает при необходимости перехода между ними, типа make/maked), библиотечку вспомогательных функций (которая пригодится в шелл скриптах) и сильно покоцанный dbus — тогда получится что-то полезное

так же (полагаю) что функциональность «запускать демон наследуя сокет, до этого уже прослушиваемый systemd» должна реализовываться без перекомпиляции демонов (силами ядра + переделанной libc), иначе на нее опять опасно полагаться

___________________________________________________________

* порезать означает поделить на части, общающиеся через фиксированные и документированные текстовые команды или что-то подобное по легкости отладки/перехвата

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

systemd надо порезать* на init, udev, *inetd, логгер, stated (это такая хрень которая хранит состояние и че-то делает при необходимости перехода между ними, типа make/maked), библиотечку вспомогательных функций (которая пригодится в шелл скриптах) и сильно покоцанный dbus — тогда получится что-то полезное

Люто, бешено плюсую. Самая адекватная мысль из высказанных в треде.

Axon ★★★★★
()

Немного офф-топ про перезапуск упавших демонов...

Коллеги!!!

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

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

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

<offtopic>Вы программист? А с программистами общались когда-нибудь? Не за бутылочкой пива в выходной, а на профессиональные темы? 95% программистов, узнав о том, что драйвер файловой системы в случае краха будет перезагружен микроядром, даже отлаживать его не станут. А зачем? Упадёт - так микроядро его автоматически поднимет. Файлы при падении могут попортиться? Так вы бекап регулярно делайте, чтоб не потерять данные. А про большие задержки в случае микроядра даже Таненбаум не спорит. ИМХО микроядро - не панацея, так что тут я на стороне Торвальдса.</offtopic>

pv4 ★★
()

Ну, кое-кто считает, что это жизненно необходимо. Видимо руки откуда-то не оттуда растут, раз часто падает у них. (если вы понимаете о чём я :-))

Более того, перезапуск всего подряд по зависимостям - тоже нормальное явление. :-)

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

systemd - это не NIH, это обширный и хорошо поддержанный Redhat проект

опять же хорошо, что rh наводят хоть какой-то порядок в авгиевых конюшнях именования (об именовании — *предсказать* как будет называеться команда работы с объектом_Х и ее ключи под юниксом просто *невозможно*, в отличие скажем даже от явы), но это все опять обесценивается комбайном

www_linux_org_ru ★★★★★
()

А не охренели ли админы такими костылями пользоваться????

Это ты ещё не слышал, какими они костылями пользуются «для упрощения операции сохранения проверочных ключей», которыми Journald шифрует логи для предотвращения их подмены.

(по мотивам http://www.opennet.ru/opennews/art.shtml?num=34630)

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

Эта задача неразрешима внутри замкнутой системы. Они не в курсе?

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

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

Это мнение человека, реально двигавшего СПО в россии с 90х годов против твоего мнения, о «надрочивший 5 звёзд на лоре».

Да у тебя Бухарест, анон. Кроме того, откуда ты знаешь, сколько я сделал для продвижения СПО? :)

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

Если у плана непонятна конечная цель, может это и не план?

Если под $WHATEVER выделены ресурсы, это план.

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

А собрать udev без systemd теперь можно, не знаешь?

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

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

да пусть rh хоть на каждую строчку кода systemd наймет по 1 работнику саппорта — это все равно будет хуже, чем иметь набор простых и понятных каждому демонов

Идеологическая чистота не интересует Redhat. И, судя по распространению systemd, она не интересует уже никого.

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

А какие низкоуровневые службы мы унаследовали от Unix? У нас что, вообще были какие-то низкоуровневые службы?

Troll harder, babe.

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

Красноглазый графоман здесь тоже не пример.

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

И, судя по распространению systemd, она не интересует уже никого.

Беда в том, что никто не решился форкнуть udev своими силами. Или что-то аналогичное.

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

Беда в том, что никто не решился форкнуть udev своими силами

ИМХО, udev трудно форкнуть - он зависит от конфигурации аппартуры, и ему нужна очень широкая тестовая база. Кто будет тестировать форк? Кроме того, sysvinit тоже нужно дорабатывать.

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

Спасибо за ссылку, поржал. Картина маслом: толпы админов, ежедневно фоткающего мониторы серверов на колокейшене в датацентре.

anonymous
()

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

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

А не охренели ли админы такими костылями пользоваться????

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

AVL2 ★★★★★
()

Пользуюсь systemd на нетбуке (Lenovo S205) несколько месяцев, полёт нормальный, никаких проблем с lock'ами и прочим. Arch, ничего, кроме unit-файлов для httpd (service+socket, хочется стартовать его по запросу) и mysqld не допиливал. ЧЯДНТ? =)

Сходу, правда, не смог разобраться с тем, как убивать httpd после X минут простоя - реализовал bash-скриптом проверку на модификацию больше X минут назад, другим скриптом из крона проверяю и останавливаю httpd, если нужно. =)

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

Идеологическая чистота не интересует Redhat. И, судя по распространению systemd, она не интересует уже никого.

Идеологическая чистота перестала инетересовать мир сразу после поражения фашизма.

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

Идеологическая чистота не интересует Redhat. И, судя по распространению systemd, она не интересует уже никого.

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

а что интересует rh думаю и ребенку ясно — vendor lock-in

p.s. скоро, думаю, к мему «убунта это не линукс» добавится еще и «rhel это не линукс»

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

Да, согласен, не использую. Хотя подумываю над этим.

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

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

p.s. скоро, думаю, к мему «убунта это не линукс» добавится еще и «rhel это не линукс»

*** зануда mode on ***

А RHEL и так не Linux, а операционная система, состоящая из огромного количества компонентов, в том числе использующая ядро Linux.

**** зануда mode off ***

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

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

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

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

Уже вышла версия 191.

Видимо, Леннарт читает этот тред и обзавидовался версии less. =)

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

Грабля в том, что все подсели на udev...

И как это тебе помешает бутануться с init=/sbin/init

поробовал я загрузить debian с запрещенным udev

типа загрузился, но pppd не запускается!

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

Нет. Потому что любой линуксоид знает баш, но далеко не любой - си.

И, да не будет он ни «дистро-независимым» (/usr/), ни «широко используемым». Останется убунта с апстартом, останется дебиан, это уже половина рынка. Останется всякая маргинальщина, embedded и просто старьё. Считай ещё -10%.

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

За себя говори.

То есть, вас интересует чистота ради чистоты, а не ради пользы: функционала, простоты поддержки, отстутствия багов, etc? =)

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

p.s. скоро, думаю, к мему «убунта это не линукс» добавится еще и «rhel это не линукс»

Предлагаю «RHEL - это NIH!» Звонко, коротко, понятно.

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

а что интересует rh думаю и ребенку ясно — vendor lock-in

systemd скоро будет везде. Если это и лок-ин, то он очень извращенный.

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

То есть, вас интересует чистота ради чистоты, а не ради пользы

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

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

в случае с дистро-независимым и широко используемым в разных случаях systemd

фантастика

даже если и сам systemd будет дистронезависим (во что я не верю, поскольку rh будет максимально в него хардкодить для обеспечения vendor lock-in), конфиги под него будут дистрозависимы

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

Нет. Потому что любой линуксоид знает баш, но далеко не любой - си.

Возможно. Я тоже не полностью согласен с выбором языка для systemd, если честно. Наверное, они выбрали Си ради производительности.

И, да не будет он ни «дистро-независимым» (/usr/),
(/usr/)

Можете подробнее раписать, что вы имели ввиду?

ни «широко используемым»

Ну, это пока ещё не факт. Вроде бы, многие дистрибутивы переползают на systemd потихоньку.

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

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

Значит, я ни разу не правильно понял «идеологическая чистота» как «чистота как идеология». Видимо, вы имели ввиду «чистота идеологии». Если да, то извините. =)

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

systemd скоро будет везде. Если это и лок-ин, то он очень извращенный

почему? вполне очевидный лок-ин — саппорт в области systemd самому себе сделать очень трудно, а rh не саппортит systemd вне продуктов rh

я кстати в порядке эксперимента попробую и от udev отказаться — посмотрю, насколько это реально

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

Эта поделка не запускается без смонтированного /usr. И, да, тебе ответили ниже.

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

в случае с дистро-независимым и широко используемым в разных случаях systemd

твой systemd даже отдельные /bin и /usr/bin раньше не поддерживал (а как щас?), как он может быть дистронезависимым?

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

я кстати в порядке эксперимента попробую и от udev отказаться — посмотрю, насколько это реально

mdev уже почти готов.

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

systemd даже отдельные /bin и /usr/bin раньше не поддерживал

Поддерживал. Объединение /bin и /usr/bin это другая идея RH, к системд непосредственного отношения не имеющая.

ИМХО он копируют некоторые решения из соляры.

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

даже если и сам systemd будет дистронезависим (во что я не верю, поскольку rh будет максимально в него хардкодить для обеспечения vendor lock-in),

Я скорее имел ввиду, что он будет один на все (или не все, но многие) дистрибутивы, вместо своих, своеобразных костылей. То, что RedHat будет «максимально в нём хардкодить» - это ещё не факт, не смотря на то, что вполне возможно.

конфиги под него будут дистрозависимы

От этого никуда не деться, да.

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

твой systemd

О да, мой личный systemd. =)

отдельные /bin и /usr/bin раньше не поддерживал

Не сталкивался, если честно.

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