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 ()

**Operating Systems Affected: Here is a list of the operating systems we have tested which are vulnerable to this attack:

Ubuntu 19.10 (systemd) Fedora (systemd) Debian 10.2 (systemd) Arch 2019.05 (systemd) Manjaro 18.1.1 (systemd)

Devuan (sysV init) MX Linux 19 (Mepis+antiX) Void Linux (runit)

Slackware 14.2 (rc.d) Deepin (rc.d) FreeBSD (rc.d) OpenBSD (rc.d)

anonymous ()

Спасибо systemd, хотя не самому systemd, в частности прогрессивному развитию в виде homed. Действительно именно этого всю жизнь и не хватало. Так мучался, так мучался. А ту радость то какая.

В чём радость? А я начал процесс переезда на BSD, и как-то приятно когда система тебя слушается.

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

Но есть один маленький нюанс - не работает нихера.

Оно и не удивительно - своё «умение» писать скрипты ты продемонстрировал выше по треду. Было бы странно если бы с настолько низкой квалификацией у тебя ещё и работало бы всё.

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

А я начал процесс переезда на BSD

Даже безотносительно удобства работы, уже за одно это стоит сказать systemd спасибо: systemd-homed ещё даже в мастер не смерджили, а он уже очищает GNU/Linux от таких как ты.

Вот это - действительно радость :)

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

Оно и не удивительно - своё «умение» писать скрипты ты продемонстрировал выше по треду.

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

Вы еще не видели while true; do sleep 1; ps … | grep ;done в исполнении подобных гениев для проверки того что сервис запущен, и примерно такая же попытка убийства zombie процессов (sic!), так как дебил не знает что это такое и зачем нужно.

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

Бывают ситуации когда такие гении в ядро лезут своими руками.

Потому мое мнение простое: systemd - необходимое зло для систем с тырпрайзным говнософтом на линуксе. Хотя я по прежнему не понимаю, почему бы не использовать там Windows который славен своей стойкостью к говнокодерам.

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

А таках как ты привлекает.

Ты тоже не осилил cp как и Lennard Pottering?

Процесс этот не моментальный, включение такого г… На это у меня есть время.

Пока ты сидишь и захлёбываешь смузи из systemd а потом будешь охать, у меня есть время на досканальное изучение BSD. Я буду знать ещё одну систему и смогу сформировать более адекватное мнение о systemd, потому что буду знать альтернативы.

Я не спорю, всё может оказаться хуже без systemd чем с systemd, но только время покажет.

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

Смотри неподавись смузи из systemd. Я не против. а моё стремление найти альтернативы прошу не трогать. Это моё право тратить своё время на поиск альтернатив. Это моё право ошибаться в этом стремлении.

Как и твоё право потом т….сь с этим homed.

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

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

у меня есть время на досканальное изучение BSD.

У тебя его нет. Смотря какой BSD? FreeBSD мертв на столе, на сервере кроме случаев WhatsApp/Netflix, и во встраиваемой технике кроме Sony и Juniper.

OpenBSD то и жив в таких системах не был особо.

потому что буду знать альтернативы. Какие же (цензура) альтернативы ты собрался искать? OpenRC или еще хуже - бздунячий RC? Если твоя альтернатива это kill по PID из файлика supermegalocalhostd.pid, то у меня для тебя плохие новости.

Там в Linux, к слову, недавно появился PIDFS. Постарайся как-нибудь его осилить. Может программку напиши, которая будет держать FD туда в состав sysvinit….

Я не спорю, всё может оказаться хуже без systemd Все было хуже без systemd.

Пока ты сидишь и захлёбываешь смузи из systemd Я не «дьювелупер».

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

бздунячий RC? Если твоя альтернатива это kill по PID из файлика supermegalocalhostd.pid, то у меня для тебя плохие новости.
Там в Linux, к слову, недавно появился PIDFS. Постарайся как-нибудь его осилить

смотрим отсталый бсд, 2011 год: man pdkill

pdkill() is functionally identical to kill(2), except that it > accepts a process descriptor, fd, rather than a PID.

man procdesc

DESCRIPTION
procdesc is a file-descriptor-oriented interface to process signalling and control,

Но это слишком прогрессивно - 2011 год, как никак.
Поэтому пользуемся технологиями 2000-х этой отсталой бзди:
Запуск:
jail -c -u someuser path=/ name='foobar' command=mycommand
останавка:
jail -r foobar
или
pkill -j foobar -signal mycommandname
если нужна совместимость и немножко странного:
pkill -j foobar -F pidfile -signal
PIDфайл есть, а гонок - нет.

или пишем сервисфайл^W скрипт:

#!/bin/sh
# PROVIDE: some_service
# REQUIRE: LOGIN
. /etc/rc.subr
name="some_service"
rcvar=some_service_enable

load_rc_config $name

start_cmd="jail -c -u someuser path=/ name='some_service_jail' command=myservice"
stop_cmd="jail -r 'some_service_jail'"
run_rc_command "$1"
Теперь можем делать:
service some_service start
service some_service stop
и никаих PID файлов или отслеживаний.

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