LINUX.ORG.RU

Выпуск systemd 244

 


0

0

Среди изменений:

  • новое лого;
  • сервисы теперь можно привязывать к CPU через cgroup v2, т.е. поддержка cpuset cgroups v2;
  • можно определить сигнал для рестарта сервиса (RestartKillSignal);
  • systemctl clean теперь работает и для юнитов типа socket, mount и swap;
  • systemd теперь пытается вычитывать конфигурацию из переменной EFI SystemdOptions как альтернатива изменения параметров ядра из загрузчика;
  • systemd отменяет лимиты printk, чтобы уж точно схватить все логи во время загрузки (и потом применяет свои лимиты);
  • добавлена поддержка загрузки настроек из директорий типа «{unit_type}.d/», чтобы применить настройки ко всем юнитам данного типа;
  • в systemctl добавлено 'stop --job-mode=triggering', чтобы останавливать и зависимые юниты;
  • улучшено отображение зависимостей в Unit status. Теперь показывает зависящие юниты и юниты, от которых зависит;
  • очередные улучшения для работы с PAM сессиями. Добавлено ограничение общего времени жизни сессии с принудительным разлогином;
  • новая группа для системных вызовов @pkey, сразу разрешает все memory syscalls для контейнеров;
  • для udev добавлена программа fido_id;
  • исправления в работе udev с CDROM;
  • systemd-networkd больше не создает маршрут по умолчанию для сетей 169.254.0.0/16 (диапазон для автоконфигурации);
  • systemd-networkd теперь может объявлять новые IPv6 маршруты;
  • systemd-networkd теперь сохраняет конфигурацию DHCP при рестарте;
  • добавлены новые опции в systemd DHCPv4 и DHCPv6 сервер;
  • в systemd-networkd добавлены опции для трафик шейпинга;
  • поддержка devicetree-overlay;
  • systemd-resolved поддерживает проверку имен через GnuTLS;
  • systemd-id128 теперь может генерировать UUID;
  • добавлено опциональное ограничение для юнитов, не позволяющее читать им логи ядра.

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

★★★★★

Проверено: Satori ()
Последнее исправление: Satori (всего исправлений: 6)

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

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

А я - могу, так что проблема определённо не в journald.

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

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

Может и можно - это как-бы не к systemd вопрос, а к KDE: хотят-ли они бесплатно поддерживать идиотов, требующих секса непрменно в гамаке.

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

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

инит на платформе электрон - вот светлое будущее.

не, это промежуточный этап. … в конце будет переписанное на js ядро (или какой сюсямд-линупс-ноуд), запускающееся в облаке.

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

Опять прибежал заеббал и тявкает на всех. Тебе, шавка, хоть платят, или ты кончиной поцтеринга питаешься?

фи, поручик … как вы могли подумать такое? … он потом сплёвывает ;)

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

Так системная возможность перезапуска способствует наплевательскому отношению. Человек так устроен.

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

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

Признавайтесь, кто играется с TensorFlow и выпустил бота на ЛОРе пастись?

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

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

да кто же вам мешает, становитесь мейнтейнерами своих любимых дистрибутивов

Если подвергнуть сомнению вышеприведённый тезис, то станет очевидно, что именно им мешает ;-)

то то ж тебя так вспучило от очередного релиза девуан, что чуть не порвался ;)

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

Когда система становится умней пользователя

Судя по твоим комментариям не только systemd уже умнее тебя - такими темпами ты скоро к стиральной машине в рабство попадёшь.

А что плохого в фряхе?

Примерно всё? Никакая производительность, неудобные интерфейсы администрирования, отсутствие поддержки кучи софта, микроскопическое сообщество…

А ведь каких-то 15 лет назад этим даже активно пользовались - просто потому, что GNU/Linux тогда был тоже весьма убог. Вот только с тех пор GNU/Linux развился в офигительно удобную систему с огромным количеством применений - от суперкомпьютеров до встраиваемых систем, а бздя где была там примерно и осталась.

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

Примерно всё? Никакая производительность, неудобные интерфейсы администрирования, отсутствие поддержки кучи софта, микроскопическое сообщество…

ну здравствуй, неспособный к чтению документации неосилятор, застывший в развитии на journalctl :D

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

Кому должна? Тебе?

Должна именно так как себя позицианировала

У тебя русский не родной что-ли? Неудивительно что ты systemd осилить не можешь - если вопрос из 2 слов тебя уже в тупик ставит.

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

насчет пулл/пуш можно было бы дать ссылки если очень хотелось помочь

Ты правда искренне считаешь, что анонимное хамло в интернете вызывает желание помочь ему? Серьёзно?

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

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

ДЕСЯТЬ ЛЕТ systemd!

Итоги треда: systemd — закопанная стюардесса, Лёня — старый красноглаз-геронтофил-пердолик, пользователи systemd — некрофилы с синдромом утёнка. Хипсторы в 2k2t не одобряют.

Grzegorz

</thread>

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

загружался

Аж в голосину! Можешь ведь когда хочешь :-D :-D :-D

zabbal ★★★★★
()

Осталось еще немного: впихнуть в systemd всю операционку, весь пользовательский софт и будет счастье)))

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

Чем плоха команда в скриптах systemctl reboot/poweroff и проч...

Тем что:

... системд... может вообще бесконечно пытаться убить процесс(за неделю можно словить этот прикол 2-5 раза)...

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

A <...> job is running for <...> (1min 30s/unlimited)

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

Неплохо иметь базовую возможность перезапуска в системе инициализации...

... намного лучше rc-скриптов.

rc-скрипт системы инициализации с базовой возможностью перезапуска сервиса.

#!/bin/bash

service=service
pidfile=/var/run/$service.pid

case $1 in
	start)(
		cpid=0
		trap "kill $cpid; rm -f $pidfile" EXIT
		trap '' HUP
		while :
		do
			service &
			cpid=$!
			wait $cpid
			logger Crash $service
		done
		)</dev/null >/dev/null 2>&1 &
		echo $! >$pidfile
	;;
	stop) kill $(<$pidfile) ;;
	*) echo Usage: $0 start/stop ;;
esac

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

rc-скрипт системы инициализации с базовой возможностью перезапуска сервиса.

Если не считать возможности гонок, то сойдет.

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

A <…> job is running for <…> (1min 30s/unlimited)

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

В любом случае systemd делает ровно то, что указано в файле сервиса, так что если в нём указаны неадекватные таймауты, то это вина автора сервиса, а не systemd.

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

rc-скрипт системы инициализации с базовой возможностью перезапуска сервиса.

Спасибо за отличный пример того, как не надо делать!

  1. Большая часть запускаемых сервисов делает двойной fork. В этом случае ваш скрипт будет в бесконечном цикле запускать всё новые и новые экземпляры сервиса.

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

  3. Не реализовано действие status.

  4. Если сервис не отреагировал на SIGTERM, то он останется запущенным, но его PID-файл уже будет удалён.

  5. Дочерние процессы сервиса могут остаться запущенными.

  6. В вашем скрипте просто изобилие состояний гонок:

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

    • Если под PID из $pidfile уже работает другой процесс, он будет убит несмотря на то, что он не имеет никакого отношения к сервису.

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

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

(И это я ещё не начал придираться к стилю программирования: местами отсутствие кавычек, фигурных скобок, set -e, set -u и проч.)

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

ну здравствуй, неспособный к чтению документации неосилятор, застывший в развитии на journalctl :D

Объясни убогим, зачем в идеальной фре есть эмулятор линукс? Эти лялиховоды постоянно что-то новое придумывают? :) А также почему идеальной системы даже близко нет в top500?

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

И чтобы дважды не вставать, почему vmx, vsrx от ждунипера с линукс ядром?

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

Warning! Обнаружен адекватный комментарий на лоре!! (несу поднос чаёв с кексом)

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

Раб-хозяин устаревшая модель

Местным должны быть понятны тенденции «совместного пользования» – сначала кодом, потом всякими вещами(man *sharing), понемногу набирающие в более развитых. Пришло вот в голову: эта тенденция началась с человеков – раньше ими нужно было «владеть», но со временем более умные нашли, как реализовать human-sharing.

Т.ч. да, владение устарело лет 200 тому, и мы нынче совместно пользуемся(*) друг другом, .

(*) почему-то это слово оскорбляет всех, кому довелось его высказать. Что плохого в «пользе»?

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

Местным должны быть понятны тенденции «совместного пользования» – сначала кодом, потом всякими вещами(man *sharing), понемногу набирающие в более развитых. Пришло вот в голову: эта тенденция началась с человеков – раньше ими нужно было «владеть», но со временем более умные нашли, как реализовать human-sharing.

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

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

инит на платформе электрон - вот моральное будущее.

Потому что всё что препятствует комфортной жизни кодо(в данном случае ёб)-макаки - аморально.

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

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

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

А так... Неужели сложно запустить демон с ключом, который не даст ему уйти в фон, сделать счётчик с таймером, блокировку, проверку PID... расставить скобки и кавычки по своему вкусу :) .

Для некоторых сервисов типа HTTP/FTP пункт 5 - вообще зло злющее.

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

бегло пробежав глазами по этому шаблону

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

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

Пришло вот в голову: эта тенденция началась с человеков – раньше ими нужно было «владеть», но со временем более умные нашли, как реализовать human-sharing.

Надеюсь ты как умный человек расшариваешь свою жену на весь квартал.

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

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

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

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

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

А так… Неужели сложно запустить демон с ключом, который не даст ему уйти в фон, сделать счётчик с таймером, блокировку, проверку PID… расставить скобки и кавычки по своему вкусу :) .

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

Для некоторых сервисов типа HTTP/FTP пункт 5 - вообще зло злющее.

systemd по умолчанию прибивает всю контрольную группу сервиса, то есть процесс вместе со всеми его потомками. Если же такое поведение нежелательно, есть директива KillMode= с несколькими вариантами, включая даже none.

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

Пришло вот в голову: эта тенденция началась с человеков – раньше ими нужно было «владеть», но со временем более умные нашли, как реализовать human-sharing.

Human-sharing — это что-то вроде права первой ночи у господ перед холопами-куколдами?

Grzegorz

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

Human-sharing — это что-то вроде

Пример: местные анонимы использовали меня для почёсывания ЧСВ. Я их для демонстрации ничтожности альтернанивного взгляда(*). Владельцы форума использовали вышеперечисленных для удержания публики. А публика(если ещё кто-то это читает) – для развлечения или уточнения своих взглядов(будем надеяться). Что не так то? Все в плюсе, кроме модераторов, пошли фармация здоровья их психике.

(*)который, как оказалось, основан лишь на оскорблениях в адрес своего интеллекта, даже без какой-ни-какой прокладки.

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

Мне интересно, сколько системд-отрицательных могут внятно объяснить свою позицию

systemd — не UNIX-way.

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

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

о, смотри, некоторые уже давно с расстегнутой ширинкой бегают

«Успешная подмена пакетов продемонстрирована для туннелей, создаваемых при помощи OpenVPN, WireGuard и IKEv2/IPSec. Для IPv4 атака возможна в случае перевода rp_filter в режим „Loose“ (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим „Strict“, но начиная с systemd 240 режим работы по умолчанию был заменён на „Loose“ и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.»

http://www.opennet.ru/opennews/art.shtml?num=51986

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

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

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

Режим 2 «Loose» смягчает проверку

ЯННП, можно расслабить анус или нет?

Grzegorz

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

Какой же ты всё-таки сказочно тупой дятел. Мало того что атака для IPv6 не требует изменения данной настройки, мало того что это настройка, которую можно тривиально поменять… дык оно ещё и лечится одной строчкой правила nft. Но виноват, разумеется, systemd. Ну потому что у дятлов он во всём виноват по-умолчанию - даже в несварении желудка хейтеров тоже systemd виноват.

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

Systemd ужасно тормозной. Как и его сторонники. Они уже начинают что-то подозревать. Но поймут нескоро.

anonymous
()

Жаль что в эту версию systemd-homed не вошёл - кроме баттхёрта хейтеров и обсудить-то толком нечего :)

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

Дык о чём? Они ж до конца года практически голосовать будут - как подведут итоги, так и имеет смысл писать.

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

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

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

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

Нужен мировой стандарт GNU/Linux. Никакого нынешнего зоопарка. Всё централизовать, DEB- и RPM-ветки слить в одну, вобрав лучшее из каждой. Gentoo оставить для IoT и прочих подобных решений. Остальное упразднить за ненадобностью.

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

Надеюсь это всё будет поэтапно реализовано.

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

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

Угу. Это здорово. Но есть один маленький нюанс - не работает нихера. Вернее, как бы и работает, но ведёт себя непредсказуемо.

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

Но есть один маленький нюанс - не работает нихера. Вернее, как бы и работает, но ведёт себя непредсказуемо.

Если не читать документацию, то всё ведёт себя неожиданно и непредсказуемо.

Вот в коде systemd что, switch (random()) где-то стоит или что? Что конкретно вы понимаете под непредсказуемостью?

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

Уязвимость, позволяющая вклиниваться в TCP-соединения, осуществляемые через VPN-туннели

/* Для IPv4 атака возможна в случае перевода rp_filter в режим «Loose» (sysctl net.ipv4.conf.all.rp_filter = 2). Изначально в большинстве систем применялся режим «Strict», но начиная с systemd 240, выпущенного в декабре прошлого года, режим работы по умолчанию был заменён на «Loose» и данное изменение отразилось в настройках по умолчанию многих дистрибутивов Linux.

*/

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