Как восстановить `/ dev / log` на хосте systemd + rsyslog?

10

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

systemd-journald rsyslogd

— Otheus
источник

13

Задавать и отвечать на мой вопрос, потому что Google не очень помог в этом вопросе.

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

Однако ожидается, что прилагаемый rsyslog RHEL7будет использоваться вместе с модулем 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он уже запущен.

— Otheus
источник

2

Большое спасибо за это! Я просто потерял несколько часов, отыскивая, почему регистрация не работает для службы. Я наконец отследил его до отсутствующего / dev / log, что привело меня к вашему решению.

— Чад Хьюникутт

4

systemctl restart systemd-journald.socket && systemctl restart rsyslogРешение не работает для меня на Ubuntu 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 все еще использует сценарии инициализации для rsyslog?

— Отей

@ Отеус с /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 = «off», тогда имя сокета слушателя по умолчанию (иначе, «сокет системного журнала» или просто «системный сокет») устанавливается в / dev / log. В противном случае, если пользователь явно установил SysSock.Use = "off", тогда rsyslog не будет прослушивать / dev / log ИЛИ ни один сокет, определенный параметром SysSock.Name, а остальная часть этого раздела не применяется.

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

В противном случае, если rsyslog работает в systemd AND / run / systemd / journal / syslog, существует (И пользователь явно не установил SysSock.Use = "off"), тогда имя сокета слушателя по умолчанию перезаписывается с помощью / run / systemd / journal / системный журнал.

Система должна перейти к шагу 3 и изменить путь по умолчанию на «/ run / systemd / journal / syslog», но вместо этого она осталась «/ var / log». Это означало, что модуль imuxsock попытается (и иногда удастся) создать сокет в / dev / log, где вместо него должна быть символическая ссылка, созданная systemd-journald-dev-log.socket. В случае, если не удастся создать настоящий сокет, символическая ссылка все равно будет удалена.

Эта документация была результатом этой проблемы на rsyslog github. Если вы хотите пропустить обсуждение и сразу перейти к изменениям, см. PR # 1 и PR # 2 соответственно.

Моим решением было просто настроить модуль imuxsock для использования пути systemd в моем /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, и в этом случае выигрывает последний, который должен быть включен.

— Адам
источник