LINUX.ORG.RU

Релиз systemd 230

 


4

8

Представлен выпуск системного менеджера systemd 230. Из новшеств можно отметить включение по умолчанию DNSSEС и режима чистки процессов пользователя после завершения сеанса, поддержку унифицированной иерархии cgroup, возможность настройки прокси ARP для сетевого интерфейса, новые типы юнитов generated и transient, новую команду systemctl revert и возможность создания виртуальных прямых сетевых ссылок между контейнерами.

Основные изменения:

  • В DNS-резолвере systemd-resolved по умолчанию включен DNSSEC. DNSSEC доступен в режиме allow-downgrade (автоматический откат на режим без DNSSEC) и может быть отключен через настройку DNSSEC в resolved.conf или на этапе сборки при указании опции configure --with-default-dnssec=no. Дистрибутивам пока не рекомендуется включать DNSSEC по умолчанию, пока не будут выявлены все возможные несовместимости режима DNSSEC с DNS-серверами.
  • В systemd-resolve добавлена возможность резолвинга DNS-записей DANE (DNS-based Authentication of Named Entities) при указании опции --tlsa и OPENPGPKEY при указании опции --openpgp, а также создания дампа raw-данных записей DNS при указании опции --raw=дамп.
  • В systemd-logind по умолчанию обеспечено принудительное завершение процессов, запущенных в составе пользовательского сеанса, после выхода пользователя из системы. Управлять принудительным завершением можно через опцию KillUserProcesses в logind.conf, которая теперь выставлена в значение yes по умолчанию, что требует отдельных настроек, если необходимо сохранить работу длительно выполняемых пользовательских процессов (для работы screen и tmux требуется специальная настройка сервисов, например, включение т.н. lingering через loginctl). Для восстановления старого поведения на этапе сборки можно указать опцию --without-kill-user-processes.
  • В systemd-logind добавлены новые настройки SessionsMax и InhibitorsMax, которые по умолчанию установлены в значение 8192.
  • В systemd-logind добавлена поддержка обновления конфигурации по сигналу SIGHUP.
  • Добавлена поддержка унифицированной иерархии cgroup (в ядре с 4.5), для задействования которой в systemd при загрузке требуется указать опцию командной строки ядра systemd.unified_cgroup_hierarchy=1. Для унифицированной иерархии также добавлен контроллер cgroup io, который дополнил контроллеры memory и pids.
  • Поддержка протокола LLDP (Link Layer Discovery Protocol) расширена возможностями использования пассивного (только приём) и активного (отправка) режимов. Пассивный режим включен по умолчанию в systemd-networkd, а активный режим включен по умолчанию в изолированных контейнерах с адресацией внутренней сети. Для просмотра статистики можно использовать команду networkctl lldp.
  • Добавлена возможность настройки уникальных идентификаторов IAID и DUID, отправляемых в запросах DHCP. Идентификаторы могут быть определены как для всей системы, так и для отдельных файлов .network при помощи опций DUIDType, DUIDRawData и IAID.
  • В systemd-networkd добавлена возможность настройки прокси ARP для отдельных сетевых интерфейсов, используя опцию ProxyArp в файлах .network. Кроме того, в файлы .netdev добавлены опции MulticastQuerier и MulticastSnooping, позволяющие включить режим отправки запросов и прослушивания IGMP-трафика.
  • В файлах .network представлена новая опция PreferredLifetime, позволяющая определить время жизни IP-адреса.
  • В DHCP-сервере, встроенном в systemd-networkd, активирована по умолчанию опция EmitRouter, включающая поле DHCP Option 3 (Router).
  • Тестовая утилита systemd-activate переименована в systemd-socket-activate и перемещена в /usr/bin.
  • В systemd-journald задействован отдельный поток для сброса прокэшированных данных на диск при закрытии файлов с журналом, что решило проблемы с задержками записи в лог на медленных дисках.
  • В journalctl добавлен новый метод вывода -o short-unix, при котором к записями в логе добавляется префикс с эпохальным (UNIX) временем (число секунд с 1970 года). Также добавлена опция --no-hostname для исключения столбца с именем хоста.
  • Устройства фреймбуфера, сканеры и 3D-принтеры теперь подключаются в режиме uaccess и доступны для вошедших в систему пользователей.
  • В опции DeviceAllow теперь можно указывать спецификаторы (начинаются с символа %).
  • В systemctl show добавлена опция --value, позволяющая вывести только содержимое заданного свойства юнита без указания его имени.
  • Для автоматически сгенерированных и созданных в процессе работы через обращения к API файлов добавлены новые типы юнитов generated и transient.
  • Добавлена новая команда systemctl revert для отката к предоставляемой поставщиком версии файла юнита в случае внесения в файл юнита локальных изменений.
  • В machinectl clean добавлена возможность автоматического удаления всех или только скрытых образов контейнеров.
  • В systemd-tmpfiles добавлен новый тип записи «e», позволяющий организовать очистку директорий, если они уже существуют.
  • В systemd-nspawn добавлена поддержка автоматического исправления UID/GID и ACL для всех файлов и директорий в контейнере для их соответствия диапазону UID/GID, выбранному при запуске контейнера.
  • В systemd-nspawn добавлена новая опция --network-zone для создания виртуальных прямых линков между контейнерами.
  • Для socket-юнитов добавлены опции TriggerLimitIntervalSec и TriggerLimitBurst для настройки лимитов на возможное число активаций в заданный промежуток времени.
  • Компонент systemd-bootchart вынесен в отдельный репозиторий.
  • Из состава удалён systemd-bus-proxyd, так как kdbus вряд ли будет принят в ядро в своём текущем виде.
  • Удалены библиотеки libsystemd-daemon.so, libsystemd-journal.so, libsystemd-id128.so и libsystemd-login.so, которые ранее были объявлены устаревшими.
  • Удалена опция Capabilities, вместо которой следует использовать AmbientCapabilities и CapabilityBoundingSet.

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

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 5)

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

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

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

До systemd не было такой единогласной поддержки upstart, где-то был sysVinit, где-то openRC, где-то что-то ещё. И upstart, вроде не пытался выйти за рамки своего прямого предназначения.

А что будет если RedHat закроет свои наработки?

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

flyshoot
()
Ответ на: комментарий от kir2yar
ldd /usr/bin/sv
	linux-vdso.so.1 (0x00007ffd1d56f000)
	libc.so.6 => /usr/lib/libc.so.6
dinama
()
Ответ на: комментарий от anonymous

вот вся суть дистро строения раздор и срачь по поводу клея. Ну а разве не так ?

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

Попытайся найти у меня еще какое-нибудь слабое место. 8)

Дитё.

Ладно.

Александр.

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

почему ты считаешь это «развитием»?

как сделать аналог systemd-analyze plot в вашей любимой системе инициализации?

anonymous
()

Подскажите кто, как узнать кто держит systemctl poweroff. Минуту примерно комп выключается.

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

как сделать аналог systemd-analyze plot в вашей любимой системе инициализации?

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

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

Нет. Гента. Поэтому мне это не нравится. systemctl poweroff --force завершает быстро работу, но при этом повреждаются скачиваемые файлы в qbittorrent.

Есть подозрение, что это i2p тупит. Надо проверить будет, предварительно его остановив.

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

Есть подозрение, что это i2p тупит. Надо проверить будет, предварительно его остановив

Нет. Не он.

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

Минуту или 90 секунд?

Запусти debug-shell.service, инициируй шатдаун, дождись висяка, переключись на девятый виртуальный терминал и сделай systemctl list-jobs. Имена задач, которые «running», в студию.

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

как сделать аналог systemd-analyze plot в вашей любимой системе инициализации?

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

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

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

Чтобы анализировать проблемы при загрузке в $INIT_NAME.

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

При чём тут вообще systemd?

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

При чём тут вообще systemd?

ok. а при чем тут другая система инициализации?

systemd-analyze позволяет выявить проблемы и боттлнеки при загрузке сервисов под управлением systemd.

У других систем инициализации таких проблем в принципе быть не может? Сомневаюсь. Так вот, как в таком случае посмотреть процесс загрузки системы с $INIT_NAME в виде няшного timeline-графика, в котором будет указано, сколько занял запуск каждого сервиса, чтобы узнать, какие сервисы тормозят? Повторюсь, не в системе с systemd, а в системе с $INIT_NAME.

Ладно, пофиг на графики. Хотя бы аналог systemd-analyze blame есть?

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

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

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

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

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

Вот где-то тут тупит:

-- Процесс остановки юнита session-1.scope был завершен.
май 24 19:13:10 home systemd[1]: session-1.scope: Stopping timed out. Killing.
май 24 19:11:50 home kdeinit5[5954]: QXcbConnection: Could not connect to display :0
май 24 19:11:50 home drkonqi[5951]: QXcbConnection: Could not connect to display :0
май 24 19:11:46 home systemd[1]: Received SIGRTMIN+20 from PID 5896 (plymouthd).
май 24 19:11:43 home systemd[1]: Stopped D-Bus System Message Bus.
-- Subject: Завершена остановка юнита dbus.service.
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Запусти debug-shell.service, инициируй шатдаун, дождись висяка, переключись на девятый виртуальный терминал и сделай systemctl list-jobs. Имена задач, которые «running», в студию.

А это сейчас попробую.

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

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

При чём здесь “какие демоны и в какой последовательности”?

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

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

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

systemd-analyze, внезапно, это как раз и есть такой инструмент, который прилагается к systemd.

разумеется он есть для каждой системы

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

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

друг, а если-бы там была кофеварка в комплекте - это тоже было-бы достоинством системы инициализации?
тупое громоздкое корпоративное софт - вот что такое систем-д.

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

При чём здесь “какие демоны и в какой последовательности”?

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

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

друг, а если-бы там была кофеварка в комплекте - это тоже было-бы достоинством системы инициализации?

Как варка кофе относится к запуску демонов? Не передёргивай, пожалуйста, и не съезжай на кривые аналогии. Это некрасиво и попахивает отсутствием аргументов.

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

Спасибо, очень было интересно твоё мнение. Так ты мне покажешь “инструмент прилагающийся к системе инициализации. разумеется он есть для каждой системы”?

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

фсцк может бежать полтора часа

А ты попробуй использовать настоящую файловую систему вместо ext*, и такой ерунды не будет случаться.

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

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

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

При чём здесь “какие демоны и в какой последовательности”?

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

Нет, ты просто постоянно куда-то в сторону съезжаешь. Задача systemd-analyze <blame|plot> не в том, чтобы показать администратору, “какие у него демоны” и “в какой последовательности они запускаются”, а чтобы показать, сколько времени запускался каждый демон. Поэтому я и спросил, при чём тут это.

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

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

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

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

Имена задач, которые «running», в студию.

JOB UNIT                                                           TYPE  STATE  
850 session-1.scope                                                stop  running
788 systemd-reboot.service                                         start waiting
828 systemd-tmpfiles-setup-dev.service                             stop  waiting
847 user.slice                                                     stop  waiting
833 systemd-vconsole-setup.service                                 stop  waiting
822 systemd-ask-password-wall.path                                 stop  waiting
829 slices.target                                                  stop  waiting
889 local-fs-pre.target                                            stop  waiting
818 avahi-daemon.socket                                            stop  waiting
831 systemd-remount-fs.service                                     stop  waiting
873 systemd-sysctl.service                                         stop  waiting
842 systemd-user-sessions.service                                  stop  waiting
799 home-alexv-windows-D.mount                                     stop  waiting
871 dbus.socket                                                    stop  waiting
802 mnt-oldhome.mount                                              stop  waiting
855 cups.path                                                      stop  waiting
821 sockets.target                                                 stop  waiting
800 run-user-1000.mount                                            stop  waiting
846 systemd-update-utmp.service                                    stop  waiting
801 mnt-oldroot.mount                                              stop  waiting
883 swap.target                                                    stop  waiting
794 local-fs.target                                                stop  waiting
867 basic.target                                                   stop  waiting
803 home.mount                                                     stop  waiting
816 systemd-logind.service                                         stop  waiting
793 tmp.mount                                                      stop  waiting
875 sysinit.target                                                 stop  waiting
880 systemd-random-seed.service                                    stop  waiting
858 systemd-fsck@dev-dis...x2d4ee0\x2d862d\x2db5561cfac5f1.service stop  waiting
787 reboot.target                                                  start waiting
805 shutdown.target                                                start waiting
837 systemd-tmpfiles-setup.service                                 stop  waiting
834 systemd-ask-password-plymouth.path                             stop  waiting
848 user-1000.slice                                                stop  waiting
890 paths.target                                                   stop  waiting
857 system-systemd\x2dfsck.slice                                   stop  waiting
789 final.target                                                   start waiting
815 remote-fs.target                                               stop  waiting
825 cups.socket                                                    stop  waiting
792 umount.target                                                  start waiting

40 jobs listed.
Loki13 ★★★★★
()
Ответ на: комментарий от intelfx

Исправлен в сабжевой версии.

Опа. Отличненько. Спасибо. Попробую обновится. Думал что у меня что-то криво настроено, а оно вон оно как оказывается.

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

Совершенно верно, это не сервера. Не вижу противоречия. За пределами локалхостов и серверов с месячными аптаймами тоже есть мир.

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

Совершенно верно, это не сервера. Не вижу противоречия. За пределами локалхостов и серверов с месячными аптаймами тоже есть мир.

А на сервера это тогда зачем?

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

А затем, что меньшее время загрузки — это не единственное (и далеко не главное) преимущество systemd. Это вообще побочный результат (который местами бывает весьма полезен).

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

И ещё тем, кто любит детерминированность и пишет нормативы на выполнение типовых операций. Сходимость конфигураций по типам серверов, перезагрузки, бэкапы, репликации, нагрузки на компоненты систем — всё это задокументировано и регулярно проверяется. А у вас как? Бардак везде, где можно и рут даже у уборщицы?

anonymous
()

Красота. )

Знатный срач. Вопрос, вывод логов ускорили или также тормозит?

И подброшу. Про стильно модно молодежно. Centos7 Задача, есть зеркало, софтварное, root на /dev/md127, нужно перенести на /dev/md1. Установка, загрузчик все штатно, файловая система xfs. Физического доступа нет, только ssh.

Вопрос где будет затык? )

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

А на сервера это тогда зачем?

По твоей логике и debian/$your_distro_name на сервера ставить нельзя, т.к. в нём kde и gnome есть, которые на веб-сервере не нужны.

Ivan_qrt ★★★★★
()

Про время загрузки.

Похрен, uptime усредненный в районе года, что 5 секунд, что 3 минуты, ну реально похрен.

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

верю, всегда верю анонимам.

А еще у тебя самый большой. Такой большой, что ты им у себя в зубах способен ковыряться, не то что остальные лошки. ))

Научи уж как жить, а то костыли надоели. )

chemistmail
()
Ответ на: Красота. ) от chemistmail

Мсье не любит прописывать uuid'ы, а любит писать названия устройств? Или забывает initramfs сгенерировать после изменения /etc/mdadm.conf?

Мсье ссзб.

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

время загрузки — это не единственное (и далеко не главное) преимущество systemd

Это не так, у systemd нет никаких преимуществ перед существующими решениями, кроме разве что давления со стороны redhat.

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

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

А причём тут systemd? По вашему до systemd всего этого не существовало? Вы ошибаетесь.

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

По твоей логике и debian/$your_distro_name на сервера ставить нельзя, т.к. в нём kde и gnome есть, которые на веб-сервере не нужны.

Debian - дистрибутив, systemd - система инициализации, а kde и gnome - среда рабочего стола. Ты сравнил мух с котлетами.

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

CVE-2015-7547, glibc remote root, исправлено февраль 2016. Ты прямо злостный ссзб, я смотрю.

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

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