Jak przywrócić `/ dev / log` na hoście systemd + rsyslog?

10

Na RHEL7 systemd-journaldprzejmuje wiele obowiązków tego, co kiedyś zostało zrobione rsyslogd. Czy to przez błąd, czy konflikt między tymi dwoma demonami, czasem /dev/logzaginie. W rezultacie programy polegające na syslog(3)wywołaniu nie będą działały poprawnie, w tym na przykład logger. Jak mogę przywrócić /dev/loggniazdo?

systemd-journald rsyslogd

— Otheus
źródło

13

Zadawanie i odpowiadanie na moje własne pytanie, ponieważ Google nie był w tym bardzo pomocny.

Zwykle przy rsyslogdpomocy imuxsockmoduł sam tworzy /dev/loggniazdo, rozłączając poprzedni wpis przed jego utworzeniem. Po rsyslogdzatrzymaniu (prawdopodobnie z powodu ponownego uruchomienia, które kończy się niepowodzeniem z powodu wadliwej konfiguracji), rsyslogd usuwa /dev/log .

Jednak dostarczony z rsyslog RHEL7ma być używany w połączeniu z systemd, a imuxsockmoduł faktycznie otworzy i usunie /run/systemd/journal/sysloggniazdo. Tymczasem /dev/logurządzenie jest tworzone przez plik serwisowy systemu, systemd-journald.socketktóry uruchamia się journald.

Najwyraźniej, niezależnie od tego, czy $imjournalmoduł jest używany, działają następujące.

Podsumowując, jeśli /dev/logzniknie:

uruchom ponownie systemd-journald.socket:

systemctl restart systemd-journald.socket

następnie uruchom ponownie rsyslogd
```
systemctl start rsyslogd
```

AKTUALIZACJA: Myślę, że restart rsyslogdmoże ponownie usunąć gniazdo, jeśli rsyslogdjest już uruchomione.

— Otheus
źródło

2

Wielkie dzięki za to! Właśnie straciłem kilka godzin na śledzenie, dlaczego rejestrowanie nie działa dla usługi. W końcu wyśledziłem to do brakującego / dev / log, który doprowadził mnie do twojego rozwiązania.

— Chad Huneycutt,

4

systemctl restart systemd-journald.socket && systemctl restart rsyslogRozwiązanie nie działa dla mnie na Ubuntu 16.04.

Zamiast tego musiałem odtworzyć /dev/logjako dowiązanie symboliczne do /run/systemd/journal/dev-log:

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

— 11181
źródło

Tak, ręczne łączenie również powinno działać. Ale trochę trudno jest zapamiętać. Pytanie: Na Ubuntu systemd-journald.socketistnieje jako usługa? Q2: może to restart rsyslogdbył problem? Może tak powinno być start rsyslogd?

— Otheus

P1: tak, istnieje. P2: nie ma restartjuż polecenia, jest servicei /etc/init.d/rsyslog.

— 11181

Przez restart rsyslogdMyślałem, że to oczywiste, miałem na myśli systemctl restart rsyslogd. Czy Ubuntu nadal używa skryptów inicjujących dla rsyslog?

— Otheus

@Otheus, /etc/init.d/rsyslog stopa następnie /etc/init.d/rsyslog startnie pomogły. Ani systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceW moim systemie nie ma zarówno /lib/systemd/system/rsyslog.servicei /etc/init.d/rsyslog. W każdym razie wolałbym nie spędzać więcej czasu na tym problemie.

— 11181

0

Dla mnie stało się to problemem z działaniem modułu imuxsock używanego w rsyslog z systememd.

W dokumentacji imuxsock omawiają , jak moduł powinien działać dla systemd. Krok 1 dotyczył problemów:

Krok 1: Wybierz nazwę gniazda systemowego

Jeśli użytkownik nie wybrał jawnie ustawienia SysSock Use = „off”, wówczas domyślną nazwą gniazda nasłuchiwania (aka „gniazdo dziennika systemu” lub po prostu „gniazdo systemu”) jest ustawiona wartość / dev / log. W przeciwnym razie, jeśli użytkownik wyraźnie ustawił SysSock Use = "off", wówczas rsyslog nie będzie nasłuchiwał / dev / log LUB żadnego gniazda zdefiniowanego przez parametr SysSock.Name, a reszta tej sekcji nie będzie miała zastosowania.

Jeśli użytkownik określił sysSock.Name = "/ path / to / custom / socket" (i nie ustawił jawnie SysSock Use = "off"), wówczas domyślna nazwa gniazda nasłuchiwania zostanie zastąpiona przez / path / to / custom / socket .

W przeciwnym razie, jeśli rsyslog działa w systemie systemd AND / run / systemd / journal / syslog istnieje ((ORAZ użytkownik nie ustawił jawnie SysSock Use = "off"), wówczas domyślna nazwa gniazda nasłuchiwania zostanie zastąpiona przez / run / systemd / journal / syslog.

System powinien przejść do kroku 3 i zmienić domyślną ścieżkę na „/ run / systemd / journal / syslog”, ale zamiast tego pozostał „/ var / log”. Oznaczało to, że moduł imuxsock spróbuje (i czasami się powiedzie) stworzyć gniazdo w / dev / log, w którym zamiast tego powinno istnieć dowiązanie symboliczne utworzone przez systemd-journald-dev-log.socket. W przypadku, gdyby nie udało się utworzyć prawdziwego gniazda, dowiązanie symboliczne byłoby nadal usuwane.

Ta dokumentacja była wynikiem tego problemu zgłoszonego na rsyslog github. Jeśli chcesz pominąć dyskusję i przejść bezpośrednio do zmian, zobacz odpowiednio PR # 1 i PR # 2 .

Moim rozwiązaniem było po prostu skonfigurowanie modułu imuxsock do używania ścieżki systemowej w moim /etc/rsyslog.conf:

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

Wydaje się, że rozwiązało to mój problem i brzmi jak dobre rozwiązanie, ponieważ wyjaśniałoby, dlaczego łącze symboliczne może zniknąć po ręcznym utworzeniu.

Jeśli patrzysz na swój system i nie ma w nim „/ run / systemd / journal / syslog”, spójrz na „syslog.socket”, aby zobaczyć, czy uruchamia się pomyślnie, ponieważ to właśnie jest odpowiedzialne za utworzenie gniazda.

systemctl status syslog.socket

Możliwe, że twoja wersja rsyslog.service nie definiuje syslog.service jako aliasu, który jest potrzebny, gdy syslog.socket próbuje aktywować tę usługę. Możliwe jest również, że wiele usług rejestrujących próbuje dokonać aliasu syslog.service, w którym to przypadku ostatnia opcja jest włączona, wygrywa.

— Adam
źródło