Come posso ripristinare `/ dev / log` nell'host systemd + rsyslog?

10

Su RHEL7, systemd-journaldassume molte delle responsabilità di ciò che è stato fatto una volta rsyslogd. Che si tratti di un bug o di un conflitto tra questi due demoni, a volte /dev/logscompare. Di conseguenza, i programmi basandosi sulla syslog(3)chiamata non funzioneranno correttamente, tra cui, ad esempio, logger. Come posso ripristinare il /dev/logsocket?

systemd-journald rsyslogd

— Otheus
fonte

13

Fare e rispondere alla mia domanda perché Google non è stato molto utile su questo.

Normalmente, con rsyslogd, il imuxsockmodulo creerà il /dev/logsocket da solo, scollegando la voce precedente prima di crearlo. Quando rsyslogdviene arrestato (probabilmente a causa del riavvio che non riesce a causa di una configurazione errata), rsyslogd rimuove /dev/log .

Tuttavia, si prevede che il rsyslog fornito con RHEL7verrà utilizzato insieme systemde il imuxsockmodulo si aprirà e rimuoverà effettivamente il /run/systemd/journal/syslogsocket. Nel frattempo, il /dev/logdispositivo viene creato dal file di servizio del sistema systemd-journald.socketche si attiva journald.

Apparentemente, indipendentemente dal fatto che il $imjournalmodulo sia utilizzato o meno , funziona come segue.

In breve, se /dev/logscompare:

riavvia systemd-journald.socket:

systemctl restart systemd-journald.socket

quindi riavviare rsyslogd
```
systemctl start rsyslogd
```

AGGIORNAMENTO: credo che restart rsyslogdpotrebbe cancellare nuovamente il socket se rsyslogdè già in esecuzione.

— Otheus
fonte

2

Grazie mille per questo! Ho perso diverse ore a rintracciare il motivo per cui la registrazione non funzionava per un servizio. Alla fine l'ho rintracciato nel file / dev / log mancante, che mi ha portato alla tua soluzione.

— Chad Huneycutt,

4

La systemctl restart systemd-journald.socket && systemctl restart rsyslogsoluzione non ha funzionato per me su Ubuntu 16.04.

Invece, ho dovuto ricreare /dev/logcome link simbolico a /run/systemd/journal/dev-log:

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

— 11181
fonte

Sì, anche il collegamento manuale dovrebbe funzionare. Ma è un po 'ingombrante da ricordare. Domanda: Su Ubuntu systemd-journald.socketesiste un servizio? Q2: forse restart rsyslogdil problema era? Forse dovrebbe semplicemente essere start rsyslogd?

— Otheus

Q1: sì, esiste. Q2: non c'è restartpiù alcun comando, c'è servicee /etc/init.d/rsyslog.

— 11181

Con restart rsyslogdHo pensato che fosse chiaro che significava systemctl restart rsyslogd. Ubuntu utilizza ancora script di init per rsyslog?

— Otheus,

@Otheus /etc/init.d/rsyslog stopseguito da /etc/init.d/rsyslog startnon ha aiutato. Né systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.servicesul mio sistema c'erano entrambi /lib/systemd/system/rsyslog.servicee /etc/init.d/rsyslog. Comunque, preferirei non dedicare più tempo a questo problema.

— 11181

0

Per me questo ha finito per essere un problema con il modo in cui il modulo imuxsock utilizzato in rsyslog funzionava con systemd.

Nella documentazione di imuxsock illustrano come il modulo dovrebbe funzionare per systemd. Il passaggio 1 era dove stavo riscontrando problemi:

Passaggio 1: selezionare il nome del socket di sistema

Se l'utente non ha scelto esplicitamente di impostare SysSock.Use = "off", il nome del socket listener predefinito (ovvero "socket del registro di sistema" o semplicemente "socket del sistema") è impostato su / dev / log. Altrimenti, se l'utente ha impostato esplicitamente SysSock.Use = "off", allora rsyslog non ascolterà on / dev / log O nessun socket definito dal parametro SysSock.Name e il resto di questa sezione non si applica.

Se l'utente ha specificato sysSock.Name = "/ path / to / custom / socket" (e non ha impostato esplicitamente SysSock.Use = "off"), il nome del socket del listener predefinito viene sovrascritto con / path / to / custom / socket .

Altrimenti, se rsyslog è in esecuzione con systemd AND / run / systemd / journal / syslog, (E l'utente non ha impostato esplicitamente SysSock.Use = "off"), il nome del socket del listener predefinito viene sovrascritto con / run / systemd / journal / syslog.

Il sistema dovrebbe essere rientrato nel passaggio 3 e modificare il percorso predefinito in "/ run / systemd / journal / syslog" ma invece sarebbe rimasto "/ var / log". Ciò significava che il modulo imuxsock avrebbe tentato (e talvolta riuscirà) di creare un socket in / dev / log dove dovrebbe invece esserci un collegamento simbolico creato da systemd-journald-dev-log.socket. Nel caso in cui non riuscisse a creare il socket reale, il collegamento simbolico verrebbe comunque rimosso.

Tale documentazione era il risultato di questo problema riportato sul rithyslog github. Se vuoi saltare la discussione e saltare direttamente alle modifiche, vedi rispettivamente PR # 1 e PR # 2 .

La mia soluzione era semplicemente configurare il modulo imuxsock per usare il percorso systemd nel mio /etc/rsyslog.conf:

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

Questo sembra aver risolto il mio problema e sembra una buona soluzione qui poiché spiegherebbe perché il collegamento simbolico potrebbe scomparire di nuovo dopo averlo creato manualmente.

Se guardi il tuo sistema e "/ run / systemd / journal / syslog" non è presente, guarda "syslog.socket" per vedere se si sta avviando con successo poiché è questo il responsabile della creazione del socket.

systemctl status syslog.socket

È possibile che la versione di rsyslog.service non definisca syslog.service come un alias necessario quando syslog.socket tenta di attivare quel servizio. È anche possibile che più servizi di registrazione provino ad alias syslog.service nel qual caso vince l'ultimo caso abilitato.

— Adamo
fonte