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)
Ответ на: комментарий от sergv

Монтирование флэшки при втыкании.

елки палки оказывается это уже задача сервис менеджера.. а раньше целиком средствами udev решалось. По второму real-live пример можно. а то все известные мне службы справлялись с изменением интерфесов сами?

Ладно, допустим то, что тут всё в одном месте и это преподносится как бонус.

Это -проблема поттерингожурнала

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

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

так вы о namespaces или конкретно о cgroups? если второе, то вопрос остаётся активным.

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

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

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

так вы о namespaces или конкретно о cgroups? если второе, то вопрос остаётся активным.

А второе - не часть первого?

One of the design goals of cgroups was to provide a unified interface to many different use cases, from controlling single processes (like nice) to whole operating system-level virtualization (like OpenVZ, Linux-VServer, LXC). Cgroups provides:

Resource limiting: groups can be set to not exceed a set memory limit — this also includes file system cache.[3] The original paper was presented at Linux Symposium and can be found at Containers: Challenges with the memory resource controller and its performance[4] Prioritization: some groups may get a larger share of CPU[5] or disk I/O throughput.[6] Accounting: to measure how much resources certain systems use for e.g. billing purposes.[7] Isolation: separate namespaces for groups, so they don't see each other's processes, network connections or files.[2] Control: freezing groups or checkpointing and restarting.[7]

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

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

вполне возможно :)

А второе - не часть первого?

с cgroups я знаком в основном по /usr/src/linux/Documentation/cgroups/cgroups.txt и проч. там про namespaces, которые: /usr/src/linux/Documentation/namespaces/compatibility-list.txt ничего не сказано, если я чего-то не знаю, то буду рад если кто отметит куда читать. Если имеется ввиду, возможность создания разных иерархий в цгруппах, то мне не совсем ясно, как это использовать для контроля доступа. Точнее я вижу один вариант, но совсем не очевидно почему это лучше контроля доступа по группам, юзеру, настоящим и эффективным и т.д.

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

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

Именно :-) Всё остальное эпично приятнуто за уши

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

Монтирование флэшки при втыкании.

а раньше целиком средствами udev решалось

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

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

Не решалось, а костылялось.

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

Удев не в курсе о текущем пользователе физического рабочего места

и что? т.е. как поступит систем-д при втыкании флешки, особо прошу рассмотреть след случай: нет xdm, на компе с tty1 запущенный иксы пользователем A, а на tty2 сидит пользователь B. В виртуальной консоли у пользователя A, открыт терминал в котором, он зашёл как пользователь C.

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

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

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

ну и отлично, так какой пользователь за компом в вышеприведённом сценарии? (и вообще почему это отражается на системе сервисов)

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

и вообще почему это отражается на системе сервисов

Это отражается на системе управления сессиями, информацию которого может использовать (или не использовать) система управления доступом

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

По идее, если у тебя на активной виртуальной консоли в иксах запущено (ну или теоретически, в чистой консоли, но такое вряд ли в консоли будет) что-то, что хочет как-то реагировать на появление флешки, то этому «чему-то» сообщат через системный dbus и дадут возможность смонтировать её. От consolekit это отличается тем, что logind обеспечивает вход в систему, и поэтому сразу создаёт сеансы при логине.

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

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

При чем тут системд и почему потребовалось logind включать в его состав?

ЕМНИМ, просто вслед за сиверсоским удавом. Для нарезания прав.

sergv
() автор топика
Ответ на: комментарий от geekless

При чем тут системд и почему потребовалось logind включать в его состав?

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

no-dashi ★★★★★
()
Ответ на: комментарий от AGUtilities

systemd конфигурируется текстовыми файлами. ничего там намертво не пришито.

Молчал бы уж, а? В systemd «конфигурируется текстовыми файлами» только то, что родилось отдельно от systemd. Пример - оторви от systemd journald. Вообще. Не «сделай так чтобы он не писал логи на диск», а именно «сделай так чтобы его вообще не было». И потом расскажи, что произошло с твоим syslog'ом.

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

Пример - оторви от systemd journald

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

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

конфигурируется текстовыми файлами

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

Мысль пока недооформлена, не хватает времени серьёзно задуматься о сущности «plain text"овости.

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

на xml не похоже. на base64 не похоже. и по-моему очень даже читабельно

getty@.service

[Unit]
Description=Getty on %I
Documentation=man:agetty(8)
After=systemd-user-sessions.service plymouth-quit-wait.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

# On systems without virtual consoles, don't start any getty. (Note
# that serial gettys are covered by serial-getty@.service, not this
# unit
ConditionPathExists=/dev/tty0

[Service]
Environment=TERM=linux
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear %I 115200
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=no
KillMode=process
IgnoreSIGPIPE=no

# Unset locale for the console getty since the console has problems
# displaying some internationalized messages.
Environment=LANG= LANGUAGE= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE= LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE= LC_MEASUREMENT= LC_IDENTIF
ICATION=

# Some login implementations ignore SIGTERM, so we send SIGHUP
# instead, to ensure that login terminates cleanly.
KillSignal=SIGHUP

[Install]
Alias=getty.target.wants/getty@tty1.service

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

«какой фиерический»

Пишется «фЕерический». ЕГЭ сказывается, видимо.

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

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

и да не избавится, там таких привязок слишком много, эта особенность системд, от которой оно не избавится, т.к. это by design. И это хорошая особенность для сферического пользователя в вакууме, которому пофиг на то, как что работает :) ну точнее будет хорошей, когда всё будет идеально отлажено.

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

таких привязок слишком много

и комбайн - две большие разницы

разные системы логирования для разных сервисов

А что, у нас сейчас так можно?

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

классические syslog-ng, r-syslog, metalog (иметь несколько не имеет смысла, но вот какую использовать может зависеть от задач)

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

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

P.S. у syslog есть интересные проблемы (хотя я не админ, чтобы утверждать, что это проблемы), но logd (или как там его) их не решает.

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

Так как мне сделать

разные системы логирования для разных сервисов

?

Ну например для постфикса я хочу syslog, а для всего остального — metalog?

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

странное желание иметь разные инстансы syslogd сервиса, это возможно только если ты части приложений скажешь слать логи на /dev/log2. А вот желаение логировать stderr, куда многие нормальные программы шлют логи, другим логгером это вполне оправданное желание.

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

странное желание иметь разные инстансы syslogd сервиса

Да, я тоже так подумал.

А вот желаение логировать stderr, куда многие нормальные программы шлют логи, другим логгером это вполне оправданное желание.

И о чудо, это есть из коробки в systemd-journald. И что?

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

А вот желаение логировать stderr...

Вообще, для этого в юниксе даже не нужно сильно приседать, всё уже изобретено до нас. Навскидку вспоминаются djb'шные daemontools.

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

И о чудо, это есть из коробки в systemd-journald. И что?

ааааа! моим логгером! или саганом, который будет висеть 1 мелким процессом на 1 лог и что-то делать, напр бзипать, подписывать и чанками по 64кб слать по сети.

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

StandardOutput=socket. Вешай свой qlog, и делай что хочешь. Я конечно сам этого не делал, но если не заработает - можно мылить баг

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

Как раз хороший пример; похоже информация в нём не только текстовая: скопипейстим текст 2 раза, и обернём один в quote второй в code, сравним:

[Unit] Description=Getty on %I Documentation=man:agetty(8) ...

и

[Unit]
Description=Getty on %I
Documentation=man:agetty(8)
...

Я бы сначала обсудил, что такое «текст», и чем он отличается от «нетекста»

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

ладно пофиг на логи и прочие вещи. Ты мне лучше расскажи знаешь ли ты зачем systemd раз в день tmp.d файлы перевыполняет?

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

так.. при загрузке выполняются все действия описанные в tmp.d файлах, в дополнение к этому эти действия перевыполняются раз в день [1], вопрос, какая на то причина, или это какой-то костыль?

[1] тут для продолжения нездоровой дискуссии можно вспомнить про reimplementing cron.

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

да и я спрашиваю, не потому, что хочу сказать, что SD отстой, а т.к. мне действительно интересно зачем это надо. А т.к. про дизайн SD у Поттеринга не почитаешь, то спрашивать у тех, кто пользуется приходится.

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

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

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

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

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

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

Понятия не имею. Может быть в федоре была какая-то такая фича. А может быть потому что может. В целом это представляется милой фичей, но на исключительно необходимую оно не тянет, да. Впрочем, тут надо уточнить, в данной плоскости это не замена, а рекомендации чистильщику.

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

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

Понятия не имею. Может быть в федоре была какая-то такая фича. А может быть потому что может. В целом это представляется милой фичей, но на исключительно необходимую оно не тянет, да. Впрочем, тут надо уточнить, в данной плоскости это не замена, а рекомендации чистильщику.

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

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

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

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

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

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

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

на стопе сервиса никак не? или ради F,D,r,R, если так, то можешь посмотреть, какие юниты это используют?

ваще костыль какой-то..

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

Причем тут стоп сервиса? Например устаревшие кеши man. Оно не обязательно привязано к сервису. Это как правило в cron, типа logrotate.

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

повторю вопрос, можешь ли ты посмотреть, какие сервисы предоставляют tmp.d файлы с правилами F,D,r,R?

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

Я не совсем понимаю что ты хочешь, так что вот:

 > find /etc/tmpfiles.d /usr/lib/tmpfiles.d/ -type f | grep -v keep | xargs equery b
 * Searching for /etc/tmpfiles.d/postgresql.conf,/etc/tmpfiles.d/pcscd.conf,/etc/tmpfiles.d/screen.conf,/etc/tmpfiles.d/nm-dispatch.conf,/usr/lib/tmpfiles.d/gentoo-run.conf,/usr/lib/tmpfiles.d/systemd.conf,/usr/lib/tmpfiles.d/tmp.conf,/usr/lib/tmpfiles.d/mysqld.conf,/usr/lib/tmpfiles.d/x11.conf ... 
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/gentoo-run.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/tmp.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/x11.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/systemd.conf)
sys-apps/systemd-units-3 (/usr/lib/tmpfiles.d/mysqld.conf)
> grep "^[FDrR]" -R /usr/lib/tmpfiles.d/ /etc/tmpfiles.d/
/usr/lib/tmpfiles.d/systemd.conf:F /run/utmp 0664 root utmp -
/usr/lib/tmpfiles.d/systemd.conf:r /forcefsck
/usr/lib/tmpfiles.d/systemd.conf:r /forcequotacheck
/usr/lib/tmpfiles.d/systemd.conf:r /fastboot
/usr/lib/tmpfiles.d/systemd.conf:F /run/nologin 0755 - - - "System is booting up."
/usr/lib/tmpfiles.d/x11.conf:r /tmp/.X[0-9]*-lock
vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin
/usr/lib/tmpfiles.d/x11.conf:r /tmp/.X[0-9]*-lock


Remove a file or directory if it exists. This may not be used to remove
non-empty directories, use R for that.

ух тыж красота..

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