Як відновити `/ dev / log` в systemd + rsyslog хості?

10

RHEL7 systemd-journaldбере на себе багато відповідальності того, що колись було зроблено rsyslogd. Будь-яка помилка чи конфлікт між цими двома демонами, іноді /dev/logзникне. В результаті, програма , яка спирається на syslog(3)виклик не працюватиме належним чином, в тому числі, наприклад, logger. Як відновити /dev/logрозетку?

systemd-journald rsyslogd

— Отей
джерело

13

Запитання та відповіді на моє власне запитання, оскільки Google не дуже допомагав у цьому.

Зазвичай з rsyslogdдопомогою imuxsockмодуля буде створено /dev/logсокет самостійно, від’єднавши попередній запис перед його створенням. Коли rsyslogdзупиняється (можливо, через перезапуск, який виходить з ладу через неправильну конфігурацію), rsyslogd видаляє /dev/log .

Однак RHEL7очікується , що rsyslog, що постачається разом із ним, буде використовуватися спільно з systemd, і imuxsockмодуль фактично відкриє і видалить /run/systemd/journal/syslogсокет. Тим часом, /dev/logпристрій створюється системним службовим файлом, systemd-journald.socketякий спрацьовує journald.

Мабуть, $imjournalвикористовується модуль чи ні , працює наступне.

Підсумовуючи, якщо /dev/logзникає:

перезапустити systemd-journald.socket:
```
systemctl restart systemd-journald.socket
```
потім перезапустіть rsyslogd
```
systemctl start rsyslogd
```

ОНОВЛЕННЯ: Я вважаю, що restart rsyslogdможе повторно видалити сокет, якщо rsyslogdвін вже працює.

— Отей
джерело

2

Дякую за це! Я просто втратив кілька годин, розслідуючи, чому ведення журналу не працює для служби. Нарешті я простежив це до відсутнього / dev / log, який привів мене до вашого рішення.

— Чад Хунейкутт

4

Для systemctl restart systemd-journald.socket && systemctl restart rsyslogUbuntu 16.04 рішення для мене не спрацювало.

Натомість мені довелося відтворити /dev/logяк символьне посилання на /run/systemd/journal/dev-log:

ln -s /run/systemd/journal/dev-log /dev/log

— 11181
джерело

Так, вручну посилання також має працювати. Але згадувати трохи непросто. Питання: У Ubuntu чи systemd-journald.socketіснує послуга? Q2: можливо, restart rsyslogdпроблема була? Може, це просто повинно бути start rsyslogd?

— Отей

Q1: так, він існує. Q2: більше немає restartкоманди, є serviceі /etc/init.d/rsyslog.

— 11181

За restart rsyslogdя думав , що це було ясно , що я мав в виду systemctl restart rsyslogd. Чи все ще Ubuntu використовує скрипти init для rsyslog?

— Отей

@Otheus з /etc/init.d/rsyslog stopподальшим /etc/init.d/rsyslog startне допомогли. Ні в systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceмоїй системі немає і обох /lib/systemd/system/rsyslog.serviceі /etc/init.d/rsyslog. У всякому разі, я б краще не витрачав більше часу на цю проблему.

— 11181

0

Для мене це виявилося проблемою з тим, як модуль imuxsock, який використовується в rsyslog, працював з systemd.

У документації на imuxsock вони описують, як модуль повинен працювати для systemd. Крок 1: я бачив проблеми:

Крок 1: Виберіть назву системної розетки

Якщо користувач явно не вибрав налаштування SysSock.Use = "вимкнено", тоді для сокета прослуховувача за замовчуванням (він же "сокет системного журналу" або просто "системний сокет") встановлюється значення / dev / log. В іншому випадку, якщо користувач явно встановив SysSock.Use = "вимкнено", то rsyslog не буде слухати увімкнення / dev / log АБО жодного сокета, визначеного параметром SysSock.Name, і решта цього розділу не застосовується.

Якщо користувач вказав sysSock.Name = "/ шлях / до / custom / socket" (а не явно встановлено SysSock.Use = "вимкнено"), то назва сокету прослуховувача за замовчуванням перезаписується з / path / to / custom / socket .

В іншому випадку, якщо rsyslog працює під системою AND / run / systemd / journal / syslog, існує ((І користувач явно не встановив SysSock.Use = "вимкнено")), тоді назва сокету прослуховувача за замовчуванням буде замінено на / run / systemd / journal / syslog.

Система повинна потрапити на крок 3 і змінити шлях за замовчуванням на "/ run / systemd / journal / syslog", але замість цього він залишився "/ var / log". Це означало, що модуль imuxsock намагатиметься (і іноді досягає успіху) створити сокет у / dev / log, де замість цього має бути символічне посилання, створене systemd-journald-dev-log.socket. У випадку, якщо б не вдалося створити справжній сокет, символічне посилання все одно буде видалено.

Ця документація стала підсумком цього випуску, про який повідомлялося на rsyslog github. Якщо ви хочете пропустити дискусію та перейти безпосередньо до змін, див. PR # 1 та PR # 2 відповідно.

Моє рішення полягало в тому, щоб просто налаштувати модуль imuxsock для використання системного шляху в моєму /etc/rsyslog.conf:

module(load="imuxsock"
    SysSock.Name="/run/systemd/journal/syslog")

Це, здається, вирішило мою проблему і звучить як хороше рішення, оскільки це пояснило б, чому символьне посилання може зникнути знову після того, як ви вручну створите його.

Якщо ви подивитеся на вашу систему, а "/ run / systemd / journal / syslog" немає, подивіться на "syslog.socket", щоб побачити, чи не запускається він успішно, оскільки саме це відповідає за створення сокета.

systemctl status syslog.socket

Можливо, ваша версія rsyslog.service не визначає syslog.service як псевдонім, який необхідний, оскільки syslog.socket намагається активувати цю послугу. Можливо також, що кілька служб реєстрації намагаються псевдоніми syslog.service, і в цьому випадку виграє остання можливість.

— Адам
джерело