LINUX.ORG.RU
ФорумAdmin

Как сделать некое в systemd

 ,


0

4

Господа спецы, подскажите две вещи в systemd, которые я самостоятельно разобрать не могу:
1. «systemctl -a» показывает юниты, которые физически на диске отсутствуют. «systemctl daemon-reload» не помогает. Это баг или фича?
2. Как сделать, чтобы journalctl выводила сообщения только одного ядра?

1. Скорее всего это виртуальные юниты, типа девайсов. Сервисы так или иначе на диске есть. Можешь сделать

systemctl show -p FragmentPath blablabla.service

что бы приблизительно понять, где оно есть.

2.

journalctl _TRANSPORT=kernel

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

Altlinux
Ну вот:

iskatel@iskatel-dsk:~$ systemctl -a --no-pager | grep error
iscsi.service                                          error  inactive dead      iscsi.service
iscsid.service                                         error  inactive dead      iscsid.service
lvm2-activation-early.service                          error  inactive dead      lvm2-activation-early.service
lvm2-activation.service                                error  inactive dead      lvm2-activation.service
named.service                                          error  inactive dead      named.service
NetworkManager.service                                 error  inactive dead      NetworkManager.service
slapd.service                                          error  inactive dead      slapd.service
syslog.service                                         error  inactive dead      syslog.service
update_wms.service                                     error  inactive dead      update_wms.service
dirsrv.target                                          error  inactive dead      dirsrv.target
remote-fs-setup.target                                 error  inactive dead      remote-fs-setup.target
syslog.target                                          error  inactive dead      syslog.target
NetworkManager например был удалён из системы, а named - вообще никогда не ставился. Физически в /etc/systemd/system этих юнитов нет и они вообще не должны были попасть в этот вывод.

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

error

Это фича. У них всех LoadError=org.freedesktop.DBus.Error.FileNotFound "No such file or directory".

Другими словами, это юниты, которые не существуют, но на которые ссылаются другие юниты. Поэтому для них были при первом обращении созданы «ошибочные» записи.

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

В моём случае это выглядит как-то так (некоторое время назад добавили более конкретный стейт not-found):

$ systemctl --all --state not-found
  UNIT                       LOAD      ACTIVE   SUB  DESCRIPTION
● plymouth-quit-wait.service not-found inactive dead plymouth-quit-wait.service
● plymouth-quit.service      not-found inactive dead plymouth-quit.service
● plymouth-start.service     not-found inactive dead plymouth-start.service
● rc-local.service           not-found inactive dead rc-local.service
● sssd.service               not-found inactive dead sssd.service
● syslog.service             not-found inactive dead syslog.service
● ypbind.service             not-found inactive dead ypbind.service
● syslog.target              not-found inactive dead syslog.target

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

8 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

Например, посмотрим на юнит rc-local.service. У меня в системе его нет, но systemd почему-то про него знает. Посмотрим на все зависимости, ассигнованные этому фантомному юниту:

$ systemctl show -p Requires,Requisite,Wants,BindsTo,PartOf,RequiredBy,WantedBy,BoundBy,ConsistsOf,Conflicts,ConflictedBy,Before,After,OnFailure,Triggers,TriggeredBy,PropagatesReloadTo,ReloadPropagatedFrom,JoinsNamespaceOf rc-local.service
Requires=
Requisite=
Wants=
BindsTo=
PartOf=
RequiredBy=
WantedBy=
BoundBy=
ConsistsOf=
Conflicts=
ConflictedBy=
Before=gdm.service
After=
OnFailure=
Triggers=
TriggeredBy=
PropagatesReloadTo=
ReloadPropagatedFrom=
JoinsNamespaceOf=

Соответственно, видим, что это из-за gdm.service: там прописана зависимость порядка от этого (несуществующего) юнита. Посмотрим на сам юнит:

$ systemctl cat gdm.service
# /usr/lib/systemd/system/gdm.service
[Unit]
Description=GNOME Display Manager

# replaces the getty
Conflicts=getty@tty1.service
After=getty@tty1.service

# replaces plymouth-quit since it quits plymouth on its own
Conflicts=
After=

# Needs all the dependencies of the services it's replacing
# pulled from getty@.service and
# (except for plymouth-quit-wait.service since it waits until
# plymouth is quit, which we do)
After=rc-local.service plymouth-start.service systemd-user-sessions.service

# GDM takes responsibility for stopping plymouth, so if it fails
# for any reason, make sure plymouth still stops
OnFailure=plymouth-quit.service

[Service]
ExecStart=/usr/bin/gdm
KillMode=mixed
Restart=always
IgnoreSIGPIPE=no
BusName=org.gnome.DisplayManager
StandardOutput=syslog
StandardError=inherit
EnvironmentFile=-/etc/locale.conf

[Install]
Alias=display-manager.service

Так и есть — указана зависимость After=rc-local.service.

В общем, это штатная ситуация. Надеюсь, стало понятнее.

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

Вопрос, а без разницы какой способ фильтрации журнала использовать «journalctl -b _TRANSPORT=kernel» или journalctl -b | grep kernel", journalctl в любом случае будет загружать в память полное содержимое журнала /var/log/journal/cd71d646b385ff0f6b7f61225536c5e4. Можно ли как-нибудь тут уменьшить расход памяти, чтобы не было тормозов при листании журнала, например сообщения разных типов по разным контейнерам раскидывать?

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

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

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

journalctl -b _TRANSPORT=kernel

Это будет фильтровать только по полю транспорта.

journalctl -b | grep kernel

А это будет искать по всему тексту.

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

сообщения разных типов по разным контейнерам раскидывать?

Нет, журнал так не умеет.

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

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

То есть тормоза при листании журнала связаны как раз с частым обращением с файловому кэшу?

Надеюсь, стало понятнее.

Спасибо за исчерпывающую информацию, но боюсь я не смогу ей воспользоваться. Для какой версии systemd данная информация актуальна? В Altlinux t7 KDesktop используется systemd версии 201, ключ --state и команда cat тут не работают. В прочем этот диалог уже был, мне сейчас проще смириться с тем, что такова концепция дистрибутива чем так глубоко залезать в кишки системы инициализации.

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

То есть тормоза при листании журнала связаны как раз с частым обращением с файловому кэшу?

Тормоза при листании журнала связаны с обращениями к диску как таковыми. Про кэш я написал для полноты картины.

Речь о том, что если грепать журнал — то он в любом случае будет весь считан с диска и преобразован в текст, а уже греп половину данных отбросит. Если фильтровать journalctl'ом, то есть вероятность того, что какие-то части журнала вообще не будут прочитаны. Но это зависит уже от ядра, настройки readahead и погоды на Марсе.

Что касается раскидывания разных типов сообщений по разным файлам — так journald просто не умеет.

Для какой версии systemd данная информация актуальна?

Не знаю, но здесь вроде нет ничего качественно специфичного для новых версий.

ключ --state

можно заменить грепом (только уже по error, а не по not-found).

команда cat

можно заменить cat /usr/lib/systemd/system/<имя-юнита>.

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

Всё-таки хочу попробовать полазить, поредактировать зависимости. Есть зависимость в юните /lib/systemd/system/network.service, там есть строка

Before=NetworkManager.service network.target
Как убрать зависимость NetworkManager.service? Создал файл /etc/systemd/system/network.service с содержанием:
[Unit]
Before=
Before=network.target
в результате не запустилось ни то, ни другое. Что сделал неправильно?

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

Что сделал неправильно?

Создал файл /etc/systemd/system/network.service

Это оверрайд всего юнита. .include /usr/lib/systemd/system/network.service забыл.

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

Более того, поскольку у тебя systemd 201 > 198, лучше не заменять юниты целиком, а дополнять.

В твоём случае нужно класть дополняющий фрагмент в /etc/systemd/system/network.service.d/something.conf. И вот там include уже не нужен.

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

Кажется опять не так сделал

iskatel@iskatel-dsk:~$ systemctl show -p Requires,Requisite,Wants,BindsTo,PartOf,RequiredBy,WantedBy,BoundBy,ConsistsOf,Conflicts,ConflictedBy,Before,After,OnFailure,Triggers,TriggeredBy,PropagatesReloadTo,ReloadPropagatedFrom,JoinsNamespaceOf NetworkManager.service
Requires=
Requisite=
Wants=
BindsTo=
PartOf=
RequiredBy=
WantedBy=
BoundBy=
ConsistsOf=
Conflicts=
ConflictedBy=
Before=
After=network.service
OnFailure=
Triggers=
TriggeredBy=
PropagatesReloadTo=
ReloadPropagatedFrom=
iskatel@iskatel-dsk:~$ cat /etc/system
systemd/        system-release  
iskatel@iskatel-dsk:~$ cat /etc/systemd/system
system/      system.conf  
iskatel@iskatel-dsk:~$ cat /etc/systemd/system/
bluetooth.target.wants/     getty@.service.d/           multipathd.service.d/       printer.target.wants/
default.target              getty.target.wants/         multi-user.target.wants/    sockets.target.wants/
default.target.wants/       graphical.target.wants/     network.service.d/          system-update.target.wants/
iskatel@iskatel-dsk:~$ cat /etc/systemd/system/network.service.d/options.conf
[Unit]
Before=
Before=network.target
Почему, несмотря на наличие дополняющего фрагмента всё равно After=network.service

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

Чёрт. Нет, это я идиот. Для зависимостей логика очистки списка (Before= ) не работает; можно только дополнять. Нужно копировать весь юнит в /etc и править.

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