Как исправить атрибут устройства последних строк журнала systemd перед выходом?

У меня есть служба systemd, которая регистрируется в stdout. Оттуда systemd захватывает STDOUT и записывает его в журнал.

Я использую общую идиому для обработки ошибки, когда я echo диагностика, а затем выхожу с ненулевым кодом ошибки:

 echo "my final error"; exit 1; 

Моя проблема в том, что эта финальная echo строка делает это в журнале, но не связана с моей «единицей». Посмотрев на journalctl -o json-pretty , я вижу, в чем разница. В окончательном каротаже отсутствуют свойства _SYSTEMD_CGROUP и _SYSTEMD_UNIT.

То, что я думаю, происходит, это своего рода состояние гонки. Я подозреваю, что сценарий bash не ждет, пока journald полностью обработает, прежде чем переходить к линии выхода. Таким образом, exit строка будет достигнута до завершения journald записи журнала. journald пытается найти unit , отправившее журнал, но теперь его не найти, так как устройство больше не работает.

Если я прав, я, вероятно, мог бы решить проблему, поставив sleep 1 перед оператором exit 1 , но есть ли лучший способ получить атрибут final logs?

Я использую версию systemd 229 на Ubuntu 16.04.

2 Solutions collect form web for “Как исправить атрибут устройства последних строк журнала systemd перед выходом?”

@ mark-stosberg, это известная проблема: journald не может атрибутировать сообщения, поступающие от процессов, которые выходили из своей группы, из-за / proc vs SCM_CREDS race

Вы можете найти обходной путь: https://github.com/systemd/systemd/issues/2913#issuecomment-219702148

попробуйте SyslogIdentifier=

Устанавливает имя процесса для префиксных строк журнала, отправленных в систему ведения журнала или в буфер журнала ядра.

и запустите journalctl _SYSTEMD_UNIT=unit + UNIT=unit + SYSLOG_IDENTIFIER=id

Я исследовал это, и, похоже, известная проблема с systemd в том, что есть запрос на перенос .

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

Это также считается открытой ошибкой в ​​CoreOS , которая использует systemd.

Ошибка также отслеживается на трекеере systemd freedesktop.org с ошибкой:

  • Ошибка 50184 – системный журнал иногда теряет _CMDLINE, _COMM, _EXE, _SYSTEMD_CGROUP, _SYSTEMD_UNIT

Дальнейшее тестирование показало, что проблема с отсутствием атрибута журнала является более серьезной с пользовательскими единицами. Я предполагаю, что это отдельная проблема. Для системных блоков состояние гонки относительно невелико и добавление sleep 1; перед тем, как выйти из сценария службы, можно добавить достаточное заполнение до того, как будет напечатан последний журнал, и выйти, чтобы обход проблемы.

  • Journald для вопросов подкачки rsyslog
  • Как сообщить журналисту перечитать его конфигурацию?
  • скрипт не может записывать в журнал systemd
  • Как предотвратить «Сообщения ядра были потеряны, так как система журнала не смогла обработать их достаточно быстро»?
  • systemd: ложь о имени процесса, используя sh -c exec idiom
  • Предоставляет ли журналу доступ ко всем журналам?
  • Как указать уровень журнала строки вывода из службы systemd?
  • Как не регистрировать некоторые сообщения в журнале systemd
  • Записывайте все передачи scp с помощью systemd-journald
  • Настроить systemd journald как для пересылки, так и для хранения в постоянном журнале?
  • Как получить xconsole для отображения сообщений в системе с помощью journald?
  • Linux и Unix - лучшая ОС в мире.