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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.