LINUX.ORG.RU

Новый релиз systemd 195

 


0

1

Lennart Poettering продолжает развивать свое творение, внося в него новые возможности. В свежевыпущенный релиз внесены следующие изменения:

  • journalctl получил новые параметры --since= и --until= для фильтрации по времени. Также теперь поддерживается фильтрация по юнитам через --unit=/-u.
  • journald теперь поддерживает ротацию и очистку журнала по времени в дополнение к уже имевшейся ротации по занимаемому месту.
  • journal теперь индексирует имеющиеся значения полей для каждого поля. Это позволяет клиенту просмотреть имеющиеся значения при фильтрации. В соответствии с этим обновлены bash completion. journalctl получил новый параметр -F для просмотра имеющихся значений, которые принимает поле в базе журнала.
  • Большее количество сообщений сервисов теперь записываются в журнал как структурированные и распознаются по идентификатору.
  • Мини-сервисы timedated, localed, которые ранее предоставляли поддержку смены времени, локали и имени хоста только из графического окружения типа GNOME, теперь имеют и минималистичные (но весьма функциональные) консольные клиенты для управления. Возможно, теперь это самый приятный способ смены настроек из командной строки, в особенности потому, что в них присутствует полный список опций и они интегрированы с bash completion.
  • Новая утилита systemd-coredumpctl для получения списка и извлечения coredump-ов из журнала.
  • Теперь дистрибутив устанавливает README-файлы в /var/log/ и /etc/rc.d/init.d, которые поясняют, куда подевались журналы и скрипты инициализации. Автор надеется, что это поможет сориентироваться зашедшему в эти, теперь пустые, каталоги.
  • В gatewayd добавлено множество возможностей таких, как режим «follow» для режима немедленной синхронизации и фильтрации.
  • gatewayd/journalctl теперь поддерживают вывод типа HTML5/JSON Server-Sent-Events.
  • Логика режима совместимости с init-скриптами SysV теперь эвристически определяет поддержку скриптом ключевого слова «reload» и только при его наличии предоставляет возможность «systemctl reload».
  • Сервисы типа oneshot не могут использовать ExecReload=.
  • При запуске пользовательского сервиса (через systemd --user) переменная окружения $MANAGERPID устанавливается в PID systemd.
  • Посылка сигнала SIGRTMIN+24 пользовательскому экземпляру systemd приводит к его немедленной остановке.
  • В browse.html теперь доступны фильтрация и просмотр детальной информации для отдельных полей.
  • «systemctl status --follow» удалено, используйте «journal -u».
  • Опции journald.conf RuntimeMinSize=, PersistentMinSize= удалены как бесполезные при настройке.

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



Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 6)
Ответ на: комментарий от anonymous

Вот именно в этом случае cgroups — это не решение, а костыль.

нет, это решение.

Любой рутовый процесс может прыгнуть в другую группу, и его уже не найдут.

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

Пример: что будет, если в systemd перезапустить сервис sshd?

я вот без понятия. Но это не единственный вариант решения. При этом когда НАДО убить всех наследников (rc-service sshd stop) это может быть хорошим решением, если sshd сфейлит всех убить само.

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

Чтобы оставить исключение исключением? Чтобы разработчики не думали, пускай падает, это нормально, systemd перезапустит?

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

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

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

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

Море способов

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

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

Элементарно, ватсон. В этом нашем «юниксвее» «инициализация» и есть «запуск отдельно взятых процессов». Зачем использовать для этих, точнее, как мы выяснили, «этой», задачи ≥2х систем?

Можно, конечно, возразить против полезности интегрированной ф-ии остановки. Правда, нам придётся придумывать какой-то способ для системы опускания узнать, что именно останавливать(как то костыли типа /var/run/*.pid - некрасиво, ненадёжно и плохорасширяемо). Например http-сервер в составе системы запуска мог бы сообщать PID-ы. Всё же проще, кажется засунуть остановку внутрь, тем более в init-е она есть.

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

О! Вагон велосипедов для решения одной, __простенькой, по большому счёту, задачи - остановка/запуск процессов__.

бугагага.

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

Может стоило бы уже написать 1 программу, которая делает это хорошо?

может. только сначала сформулируй, что не устраивает в имеющихся

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

Чтобы оставить исключение исключением?

Ты действительно настолько наивен? Почитай разные рассылки про исправления ошибок. Исключением является программа, ведущая себя «правильно». Обеспечить это для _всех_ возникающих IRL случаев довольно трудно, а программисты не настолько идеалистично настроены, чтобы этого добиваться. Такова реальная жизнь; большинство программ падают/зависают/тормозят когда им этого захочется; и хорошо, если система мониторинга скажет об этом дежурной смене, и тем удастся быстро вычистить/перезапустить всё нужное(не тронув всё ненужное). И да, для разборок лучше пользоваться корками и логами, а не лежащим сервисом.

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

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

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

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

сформулируй, что не устраивает в имеющихся

init: нет возможности остановить/запустить одиночный сервис; неустранимо без полной переделки. init+initscripts: при перестарте демонов новые запускаются с auid оператора, догадайся потом, что это не он систему ломает, а демон работает; неустранимо by design. daemontools: это будет уже минимум 3я система управления в канонической поставке (если inetd не считать) — догадайся, как остановить/запустить, скажем, хзчтоd; к тому же, когда я прошлый раз смотрел, они были настолько монструозны, что я предпочёл свой велосипед напартачить.

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

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

бездумное переподнимание может наделать проблем еще больше, чем было

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

почему, скажи, демонтулсы не ставят на каждый второй сервер

Не каждый второй сервер гоняет достаточно критичные к времени простоя программы - при возможности таки интересно разобраться. Или потому, что ребут системы чистит всё намного лучше. Или потому, что они некрасивы(IMHO). Или потому, что не каждый сервис адекватно ложится в их систему управления (у меня минимум 2 таких, которым, кажется, никакой бебиситтер не поможет). И в дистрибутиве его нет, сопровождать лень.

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

что за претензия к демонтулзам

У меня уже есть init, initscripts и xinetd(и, местами,heartbeat) — ставить четвёртого/пятого - перебор.

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

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

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

Не каждый второй сервер гоняет достаточно критичные к времени простоя программы

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

Или потому, что ребут системы чистит всё намного лучше

а, виндовс вей, все понятно

Или потому, что не каждый сервис адекватно ложится в их систему управления

например?

у меня минимум 2 таких, которым, кажется, никакой бебиситтер не поможет

от кривых сервисов костыли не спасут, о чем и речь

И в дистрибутиве его нет, сопровождать лень.

у меня есть сервер на дебиане с демонтулсами, ставил из официальной репы.

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

О! Вагон велосипедов для решения одной, простенькой, по большому счёту, задачи - остановка/запуск процессов.

Задача не одна. Их много, каждый сервис может запускаться и останавливаться по-разному. Некоторые сервисы могут плодить несколько процессов (см. httpd), другие создавать гигантское дерево (sshd), третьи вообще работать без процессов (iptables). Кроме того в реальной жизни всем пофиг, запущен процесс или нет, волнует только вопрос: работает он или нет. И на этот вопрос init ответить не может, да это и не его задача. Зато так ненавистные леннарту initscripts могут ответить на этот вопрос, и, пожалуй, никто не ответит на него лучше.

Может стоило бы уже написать 1 программу, которая делает это хорошо?

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

Элементарно, ватсон. В этом нашем «юниксвее» «инициализация» и есть «запуск отдельно взятых процессов».

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

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

init: нет возможности остановить/запустить одиночный сервис; неустранимо без полной переделки.

Вообще-то, runlevel-ы решают эту проблему. Но «остановить/запустить одиночный сервис» не имеет никакого отношения к системе инициализации. Вообще никакого.

init+initscripts: при перестарте демонов новые запускаются с auid оператора, догадайся потом, что это не он систему ломает, а демон работает; неустранимо by design.

Интересно, для чего тогда изобрели команды service/invoke-rc.d? И, кстати, что за auid?

daemontools: это будет уже минимум 3я система управления в канонической поставке (если inetd не считать) — догадайся, как остановить/запустить, скажем, хзчтоd;

`svc -d` что-ли?

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

Хоть попроще, чем systemd. А вообще, у каждой задачи свои инструменты. Для простых задач простые инструменты удобнее. Это нормально.

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

Демонтулз? Монструозны?! Может, это какие-то не те демонтулзы были? :)

Вообще, поделки DJB можно обвинять в чём угодно: в том, что написаны на идиотском по стилистике C, в том, что конфигурационные файлы имеют странноватый синтаксис, в том, что для наворотов конфигурации придётся писать уникальные и часто невоспроизводимые shell-скрипты, увязывающие требуемые программы в хитрозагнутую под особенности задачи и/или окружения цепочку вызовов. Но оно всё - как автомат Калашникова, если тебя один раз на... научили его разбирать-собирать, то потом ты будешь делать это хоть с завязанными глазами, хоть со связанными руками.

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

Кроме того в реальной жизни всем пофиг, запущен процесс или нет, волнует только вопрос: работает он или нет. И на этот вопрос init ответить не может, да это и не его задача.

Стакан портера этому господину!

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

можно терять не только на простое

Правильно; но это ведь не повод не минимизировать потери от простоя, когда это безопасно?

от кривых сервисов костыли не спасут

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

системд, значит, панацея

Ты сказал.

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

Правильно; но это ведь не повод не минимизировать потери от простоя, когда это безопасно?

может и не повод, но на кой ляд это в ините то? проблем с демонтулзами мы так и не услышали.

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

утомил. демонтулз подходит большинству. опровергни.

Ты сказал.

знак вопроса ты специально не увидел?

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

демонтулз подходит большинству

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

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

Задача не одна

Это как сформулировать. Давай, к примеру, посмотрим на initscripts от приведенных тобой iptables, httpd, sshd. Там, AFAIR(посмотреть сейчас негде, дома уже systemd) 90% копипейст, несмотря на то, что они «такие разные». Т.ч. я, пока, остаюсь при мнении, что задача запуска таки одна.

Задачи мониторинга работоспособности разные; правда у них есть одна общая черта - согласно конвенции процесс, завершившийся со status<>0 - не работает; можно/нужно ли его перезапускать - зависит от процесса, т.ч. должно либо конфигуриться(как в init и systemd), либо выноситься во внешнюю прогу(как в daemontools). Первое неюниксвейно, второе захламляет список процессов. Я, к примеру, молюсь реже, чем ps запускаю, т.ч. предпочитаю первое. YMMV.

Задачи остановки, согласно канонам, должны были бы быть одинаковыми, kill(2). Но тут опять компромисс - есть ядерные сервисы, ему недоступные. Тут мы вынуждены приспосабливаться к особенностям монолитной архитектуры ядра, и включению туда чего ни попадя. И есть программы, не способные корректно остановиться, когда попросят. Эти недостатки _других_ программ приводят к тому, что задача остановки вынуждено заменяется задачей старта(скриптов зачистки). А поскольку стартовать уже умеет система инициализации, логично это ей и поручить.

Итого, и инит и системд выглядят _одинаково_ гов^Wкомпромисными реализациями, а демонтулс - кошерным геморроегеном.

перезапуск упавших процессов к инициализации уже не относится

Опять же, задача не относится. Но программа, которая уже умеет делать остановку и запуск(как мы выяснили, это относится к инициализации), является первым кандидатом на роль перезапускалки.

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

runlevel-ы решают эту проблему ...

... если сервисов не больше 4(в линуске чуть больше, порядка 7)... Тебе столько хватает?

что за auid

man pam_loginuid. Очень нужная параноикам штука.

svc -d` что-ли?

Нет; init 4 или service whatewer или что там с xinetd или svc -d или su - юзер svc -d.

попроще, чем systemd

Помнишь про "... не проще, чем это необходимо"?

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

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

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

нет. то про, что ты говоришь это минимум PID-1, supervision, service-management, и если ты хочешь их склеивать в одно, при этом такие задачи как: 1) перезагрузка конфига, 2). поддержание сервиса в доступном состоянии, не должны и не могут решаться в общем случае. Так как а). задачей автоматической перезагрузкой конфига должен заниматься только сервис, б). неавтоматическая перезагрузка лога это хук restart() {}, в котором пишется сервисноспецифичное решение. Поддержка сервиса в доступном состоянии (точнее проверка его доступности) это вообще задача системы мониторинга, т.к. адекватная проверка доступности в некоторых случаях может быть сложнее, чем весь инит комплекс. Про перезапуск сервиса и почему это плохо автоматом, и к чему это может привести тут уже писали 100 раз.

Итого, что есть:

PID-1: получение pid-1 от инициализатора системы, поддержание системы в норм состоянии, перецепление процессов без родителей, дроп в resque shell в случае проблем, отдача управленяю финализатору системы, (бонусы), поддержка init уровней (?),

Supervision: наблюдение за созданными сервисами, перезапуск (или хук) в случае падения, (бонусы)

Service-management: запуск сервиса и зависимостей, переход на разные уровни сервисов, показ статуса сервиса, выполнение команд сервиса, (бонусы)

Лог-сервис: сервис или куча процессов осуществяющих логирование.

Есть интересные реализации, которые пихают дефолтную систему логирования и супервижн в init систему, но и у них идёт разделение PID-1 -> хранитель-сервиса -> сервис.

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

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

Поттеринг напел (

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

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от qnikst

Разрезать супервизор и pid1 можно только если в этот самый pid1 засунуть IPC для сообщения супервизору об убитых чайлдах. Там в любом случае будет какой-то протокол, и скорее всего эта вся борода будет в одной поставке идти. Я не думаю что в этом есть смысл. Вопрос о «неубиваемости» pid1 в данном контексте не имеет смысла: в случае стейтфулл системы мониторинга сложным компонентом будет именно она, и выход её из строя все равно грохнет основную функциональность.

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

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

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

умалчивании того, что потеряете

и что же именно пользователи потеряют от перехода на systemd? конкретно, по пунктам, пжлст.

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

Разрезать супервизор и pid1 можно только если в этот самый pid1 засунуть IPC для сообщения супервизору об убитых чайлдах.

s6 и даймонтулзы вот не объединяют. И в s6 инит на 500 строк си кода с комментариями при этом :). А решений несколько: 1). запускать прослойку 2). привязываться к процессу сокетом и слушать как он сдохнет. 3). реальная магия. В случаях сложнее agetty нужно последнее :)

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

openrc это только менеджер сервисов, он не решает ни задач s-vision, ни задач инита.

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

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

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

А решений несколько: 1). запускать прослойку 2). привязываться к процессу сокетом и слушать как он сдохнет. 3). реальная магия

Что самое смешное, неработающий демон не обязательно должен умереть как процесс :)

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

запускать прослойку

Затратно, но реально

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

Не совсем понимаю как это должно работать, тем более некоторые идиотские сервисы любят делать for (....) close(fd).

openrc это только менеджер сервисов, он не решает ни задач s-vision, ни задач инита.

Про супервизор я зря написал, да. openrc был приведен как пример системы со стейтом и с внешним хранением

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

никто так и не сказал, почему именно он должен это делать

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

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

Кстати, вот ещё так никто и не назвал, что именно у них падает постоянно. У меня вот на днях mysql упал, потому что inode кончились на винте. Вот и какой смысл был бы в таком случае перезапускать его постоянно? Пользы нет, а вред есть.

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

Ну а разве это нормально, когда спрашиваешь у инита о статусе демона и он говорит «а хрен его знает, меня это не касается, я только пускалка бинарников».

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

Хз, может нормально, может нет. Мне в дебиане по /etc/init.d/somed status говорят статус, как ни странно.

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

А зачем выдавать за определение собственные догадки?

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

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

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

стоит чему-то довестись до ума, как это ломают

Не «ломают», а «не пишут дальше». Но с таким количеством обожателей sysvinitу-то такая судьба точно не светит.

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

Именно ломают, агрессивно проталкивая. sysvinit то не умрёт, но толку от него, если перестанут писать init-скрипты?

К тому же, я всецело ЗА упрощение init-скриптов, но действительно ли это революционное изменение, а не эволюционное?

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

Я вот смотрю как нынешние браузеры с их SaaS бодро шагают по граблям, которые были пройдены в становлении современных оконных систем, и становится грустно. Сколько времени люди теряют на этом даром. Та же история, скажем, с андроидом... Много такого. Зачем это всё?

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

агрессивно проталкивая

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

перестанут писать init-скрипты

то есть sysvinit c батниками необходим толпе народу, но в то же время писать батники внезапно станет некому? вы ничего не упускаете?

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

Я называл в каком-то очередном срачетреде. synergyc, emacs и скайп - вот то что у меня регулярно перезапускается после громкого краша :D

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

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

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

зачем вы юродствуете?

то есть sysvinit c батниками необходим толпе народу, но в то же время писать батники внезапно станет некому? вы ничего не упускаете?

Писать мало. Вот что вы посоветуете пользователям arch, которые не хотят systemd? Форк?

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