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)

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

Что конкретно всем так не нравится в systemd? Почему upstart все добром считали? А systemd, который на голову выше других систем, все в штыки встречают.

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

Просто раньше не находилось смелых людей, которые ради програсса были готовы бросить камень в застоявшееся болото unix-like ОСей. MacOS X не в счёт, эту ОС профессионалы не приняли в силу большой её огороженности. И все сразу всполошились, как жабы в болоте. Кто камень кинул? Кто замахнулся на святое? На мумию Unix System V? И понеслось. Не знают что такое systemd, не используют его, но осуждают. Откуда столько предубеждения и лицемерия? Когда Линус пропихивает в ядро стопятсот специфичных для Linux вещей - это нормально. Но systemd и страшный Wayland надо закопать... Они же самим своим существованием доказывают, что что догмы олдскульных адептов Linux не всегда стоит принимать за чистую монету. Что бородатые дядьки ошибаться уменют, и писать софт, работающий очень неэффективно. Облажались бородатые, и теперь пытаются прикрыться фиговым листочком. А их последователи и себе вторят на куче ресурсов: не читал, но осуждаю. Это просто маразм какой-то.

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

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

с одного линукса на другой мигрировать проще

может быть проще чем терпеть и заставлять себя пользоваться систэмГэ? Тем более, что в течении лет 5-7 в рхеле оно не будет, и есть время :)

Вопрос в том, что мигрировать особо не куда

Что требуется от системы? Что не может вам дать один линукс, что даёт другой? ;)

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

Программисты такого уровня не занимаются администрированием и техподдержкой. Админы обычно просто программисты-недоучки. Или эникейщики. Им до Поттеринга, как пешком до Луны. Он по сути не просто программист, а системный архитектор. Сам проектирует и реализует новые фичи в системе... Есть тикет в багтрекере(оставленный бедным админом), Поттеринг выкатит патч к своему подделию. Нет тикета, так это проблема админа... Следить за сервисом и перезапускать его - админское дело. Кто на что учился... Строчить тикеты в багтрекер - тоже админское дело. А вот рассуждать как лучше init накатать, не админское дело. Далеко не каждый программист с ним справится. Многие из них проектировать приложения не умеют. Особенно сложные. Им дали задание модуль накатать, они и пишут. А для чего он, им как-то побоку... Каждый специалист должен далать своё дело, делать хорошо. В RedHat есть куча людей, которые только поддержкой и занимаются. Это люди, которые имеют такой опыт, который другим и не снился. Но Поттеринг не из их числа. Так-же как и Линус:)

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

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

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

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

petrosyan-mode: показывает окно с предложением отправить отчёт об ошибке и единственной кнопкой «Reboot».

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

Что делать. Жизнь заставила PHP использовать. И вёрсткой заниматься. А это ещё более неинтеллектуальное занятие, и довольно нудное. Но мне нравится. Особенно когда виден результат.

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

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

Если такое будет, то зачем тратить время и усилия и ячейки памяти на освоение этого преходящего г-на? systemd, ... , spaced, superinit... Вам больше делать нечего, как сидеть и гнаться за иллюзией прогресса?

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

Конечно умеет. Да и dbus используется для связи зависимых сервисов. Она создаётся ещё до их запуска, и гарантирует что сервис A при любом раскладе загрузится только если нужные ему сервис B тоже будет запущен. При асинхронном запуске шина сообщений нужна, что-бы сервисы запускались вместе со своими зависимостями. Можно было свою шину сообщений создать, но это было-бы ещё одним велосипедостроением.

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

Ещё Эклесиаст писал: «Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем». Мы постоянно гонимся за чем-то новым. Это нормально для человека. А потом замечаем, что новое - это всего лишь хорошо забытое старое. Что-бы показать приемственность systemd по отношению к systemv, Поттеринг его так назвал. systemv - это System V(5), а systemd - System D(500). Поттеринг ловко обыграл в названии как приемсвенность некоторых идей init, так и разницу между новой и старой системами инициализации. Ядро развивалось десятилетиями, а система инициализации практически не развивалась. То, что нам кажется новым, когда-то станет привычным, потом старым, потом ненужным. Сложное со временем упрощают, а простые решения обрастают ворохом сложных решений... Это и называется жизнь. Постоянное стремление к переменам, которое на деле всего-лишь бег белки в колесе.

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

Админы в нашем мире делают только то, что им сказал менеджер. У них нет достаточной квалификации, что-бы учить программистов как им приложения писать. Их дело сопровождать те приложения, которые кто-то накатал. И минимизировать риски, которые естественным образом возникают при работе любого ПО, немного более сложного, чем Hello World.

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

Он по сути не просто программист, а системный архитектор.

Итить-колотить. Может надо с большой буквы писать и с придыханием Системный Архитектор? Ещё икону повесь в правом углу и бей поклоны поццерингу.

Следить за сервисом и перезапускать его - админское дело.

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

В RedHat есть куча людей, которые только поддержкой и занимаются. Это люди, которые имеют такой опыт, который другим и не снился.

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

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

Мы постоянно гонимся за чем-то новым.

не Мы, а Ты. Есть люди которые этим неврозом не страдают.

Это нормально для человека.

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

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

Печальная у тебя жизнь. Бессмысленная.

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

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

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

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

Но ведь если ваш init рухнет, то не запустит основной скрипт. Да и нет у меня /etc/inittab, мне он даром не нужен. Я писал когда-то скрипты для своих нужд, но никогда не трогал основной скрипт. Всё что мне нужно, находил в init.d и rc<X>.d

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

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

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

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

Смешной ты однако и нифига не понимаешь ни в админах, ни программистах.

К твоему сведению, любой сколько-нибудь опытный программер прежде чем не то что кодить, а даже описывать предметную область ПО, обязательно проконсультируется с админами на предмет требований к своему проекту в смысле нагрузки, безопасности и удобства эксплуатации. Потому что в этой области программистов можно и нужно учить, ибо тут они, как правило, слабы. А консультация специалиста-эксплуатационника еще ни одному производственнику-программеру не повредила. «Это я тебе голуба, говорю как краевед» (с) Сказ о Федоте Стрельце

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

Менеждер и системный архитектор обычно имеют навыки написания и проктирования программ.

Архитектор - однозначно, а менагер - вовсе не факт. В конце-концов, что бы строить диаграммы Ганта навыки написания ПО как бы не нужны.

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

Что конкретно всем так не нравится в systemd? Почему upstart все добром считали? А systemd, который на голову выше других систем, все в штыки встречают.

Честно сказать я уже задолбался отвечать на этот вопрос. Ну, ладно - в последний раз.

Потому что:

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

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

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

- потому что я знаю Поттеринга (в отличие от Линуса), как неряшливого программиста, слабо документирующего свои поделия, и ни в грош не ставящего мнения коллег из других проектов

Словом, если подытожить, то я сильно сомневаюсь в пригодности архитектуры этого проекта для нагруженных серверов, и совсем не сомневаюсь в криворукости Поттеринга

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

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

Можно даже больше сказать - что трогать логгер вообще тупо. Потому что существуют тонны железок работающих по сислог. И никто в жизни там ничего править не будет.

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

Потому что это кривое УГ вместе с негролинуксом кроме хомячков никому не нужно.

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

Но ведь если ваш init рухнет, то не запустит основной скрипт.

И…? Это к чему вообще? Да и шансов наткнуться на крэш init'а куда меньше, чем с systemd.

Да и нет у меня /etc/inittab

На системе с обычным sysvinit? Не верю! ©

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

Зачем тебе статический /dev только из-за того, что udev собирается из одного дерева сорцов с systemd?

1. не обязательно статический

2. сечас пока что собирается

Ты точно понимаешь, для чего нужен udev?

хорошо понимаю — для того, чтобы добавлять мне ненужные проблемы

раньше всегда интерфейсы eth* определялись исходя из положения сетевой карты в слоте; потом внезапно приделали свистелку-перделку — правило для udev, которое стало их именовать исходя из своих соображений

и реальный случай — сетевушка в сервере в другом городе накрылась, эникейщики поменять ее могут без проблем, но сервер смотрит в инет только через eth2, который привязан udev-ом к Призраку Умершей Сетевушки

спасибо правилам udev-a!

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

зато декларативный

чувак, ты вообще видел текующие скрипты инициализации в дебиане? нет?

user@host $ cat /etc/init.d/ssh 
#! /bin/sh

### BEGIN INIT INFO
# Provides:             sshd
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:
# Short-Description:    OpenBSD Secure Shell server
### END INIT INFO

set -e

# /etc/init.d/ssh: start and stop the OpenBSD "secure shell(tm)" daemon

test -x /usr/sbin/sshd || exit 0

... дальше поскипано

обрати внимание на декларативность — тут тоже можно искать кольцевые зависимости и т.д.

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

чувак, ты вообще видел текующие скрипты инициализации в дебиане? нет?

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

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

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

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

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

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

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

Надо было сразу написать "...рад представить на суд аналитиков ЛОРа очередной релиз..." - получился бы эталонный вброс :)

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

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

полная ерунда — systemd отнюдь не первая система инициализации

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

Админы в нашем мире делают только то, что им сказал менеджер. У них нет достаточной квалификации,

Да, не просто в вашем мире...

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

В нашем это делают обычные эникеи...

И минимизировать риски, которые естественным образом возникают при работе
любого ПО, немного более сложного, чем Hello World.

А тамагочить ПО такого уровня, вообще, забота пользователя.

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

это нормально?

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

вообще непонятно, что и как именно запускается

читайте маны. читайте исходники. systemd-analyze вот картинки рисует.

можно и канделябром огрести…

сорта говна. честно.

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

раньше всегда интерфейсы eth* определялись исходя из положения сетевой карты в слоте

Никогда такого не было

Обана... а как было?

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

Менеждер и системный архитектор обычно имеют навыки написания и проктирования программ.

А системный администратор - навыки приведения их говнокода в условно рабочее состояние.

Я не знаю ни одного хорошего сисадмина, который не знал бы несколько языков программирования. Может не в совершенстве, как кодер, который постоянно пишет, но на уровне, допускающем изучение кода и отлов каких-то ошибок - это однозначно. Плюс написание скриптов и т.п. У Cisco, вон, у VoIP-железок скрипты на tcl. bash - про это говорить нечего. php - когда на хостинге поделие кодера начинает корки мочить, проще, конечно, загасить виртуальный хост, но, иногда, надо кодеру помочь. Открываешь книжку, читаешь про базовые конструкции, лезешь искать ошибки. Потом тыкаешь в них носом этого, с позволения сказать, программиста... C/C++ - а пакет собрать. Оно не всегда собирается. А, бывает, надо и починить. Perl, опять же. А куда без него ? И это всё помимо сисадминских непосредственных дел. Которые, кстати, значительно можно упростить, умея что-нибудь на чём-нибудь написать.

Я вот, в бытность студентом лет 15 назад, ещё и на PC-шном ассемблере писал. А тут «программист». Тьфу. :-)
А на системного архитектора Леннарт не тянет. Судя по сбору яиц в одну корзинку.

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

Было у тебя eth0 и eth1. Вытащил eth0, остался eth0. Или я ошибаюсь?

Всё правильно. Вытаскиваешь карту из слота, ставишь однотипную - ничего не меняется. И что, это не «исходя из положения карты в слоте»?

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

Конечно нет. Это называется - в порядке последовательности инициализации. Очень круто, когда она всегда одинакова. Тем не менее, это никак не «исходя из положения карты в слоте»

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

Никогда такого не было

?

у тебя есть более точная формулировка?

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

спасибо правилам udev-a!

То есть техподдержка не в курсе в каком файле нужно удалить строку привязки к мак-адресу для имени сетевухи?
Продолжай искать виноватых. У тебя получается. Один ты умный в пальто белом.

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

Это называется - в порядке последовательности инициализации. Очень круто, когда она всегда одинакова.

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

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

Равно как и мне твой, дедушка. На том и порешим.

Ну порешай, потешь своё чсв.

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

Пока что лучше всех знает, что нужно пользователям, некий Поттеринг. И, как говорит коллега tailgunner, это печально.

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

Ну ок. Было у меня eth0 и eth1 в pci. Сунул я в usb свисток, который отдает себя как eth. Вопрос — что будет после загрузки, и от чего это зависит

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

Ну, как было. Было у тебя eth0 и eth1. Вытащил eth0, остался eth0. Или я ошибаюсь?

Он имеет ввиду, что были у тебя eth0 и eth1, сгорел eth0, поменял его на другой, и, снова, у тебя eth0 и eth1. И никто ничего не перепутал. Но да, на самом деле это было не очень гарантирванно и зависело от ряда факторов, как то реализация драйвера, если сетевухи одинаковые, либо от порядка загрузки модулей, если они разные. Короче, там хватало нюансов. С другой стороны, udev тут не хуже, так как привязка к MAC - это просто вариант по-умолчанию, а привязку можно и к pci сделать. В теории.

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

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

У меня всё ещё alsa.

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

Вопрос — что будет после загрузки, и от чего это зависит

Зависит от порядка загрузки драйверов. Свисток будет либо eth0, либо eth2 (что наиболее вероятно).

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

в приличных дистрах исходники текущей версии любого пакета скачиваются одной командой.

Ты забываешь одну вещь — обычно в скрипты инициализации лезут, когда что-то идёт не так. Может даже совсем не так. Может даже машина грузится только с «init=/bin/bash», а значит никаких тебе интернетов, dbus'ов…

читайте маны. читайте исходники. systemd-analyze вот картинки рисует.

- Так, почему сервер до сих пор не работает? Какого <censored>?!
- Иван Иванович, подождите, мне тут systemd-analyze такие классные картинки рисует…

сорта <beep>. честно.

Эникей-мышевоз? :)

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

Спасибо, я понимаю что он имеет в виду. Так же я понимаю, что он не встречался с проблемами связанные с именованием и порядком инициализации устройств

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