Comment restaurer `/ dev / log` dans l'hôte systemd + rsyslog?

10

Sur RHEL7, systemd-journaldprend en charge de nombreuses responsabilités de ce qui était autrefois effectué par rsyslogd. Que ce soit par bug ou par conflit entre ces deux démons, parfois /dev/logdisparaîtra. Par conséquent, les programmes fondés sur l' syslog(3)appel ne fonctionnent pas correctement, y compris, par exemple, logger. Comment puis-je restaurer le /dev/logsocket?

systemd-journald rsyslogd

— Otheus
source

13

Poser et répondre à ma propre question, car Google n'a pas été très utile à ce sujet.

Normalement, avec rsyslogd, le imuxsockmodule créera le /dev/logsocket de lui-même, dissociant l'entrée précédente avant de le créer. Quand rsyslogdest arrêté (peut-être parce que le redémarrage échoue en raison d'une configuration défectueuse), rsyslogd supprime /dev/log .

Cependant, le rsyslog fourni avec RHEL7devrait être utilisé en conjonction avec systemd, et le imuxsockmodule ouvrira et supprimera le /run/systemd/journal/syslogsocket. Pendant ce temps, le /dev/logpériphérique est créé par le fichier de service système systemd-journald.socketqui se déclenche journald.

Apparemment, que le $imjournalmodule soit utilisé ou non , les travaux suivants fonctionnent.

En somme, si /dev/logdisparaît:

redémarrez systemd-journald.socket:

systemctl restart systemd-journald.socket

puis redémarrez rsyslogd
```
systemctl start rsyslogd
```

MISE À JOUR: Je pense que restart rsyslogdpourrait supprimer à nouveau le socket si rsyslogdest déjà en cours d'exécution.

— Otheus
source

2

Merci beaucoup pour cela! Je viens de perdre plusieurs heures à découvrir pourquoi la journalisation ne fonctionnait pas pour un service. Je l'ai finalement retrouvé dans le fichier / dev / log manquant, ce qui m'a conduit à votre solution.

— Chad Huneycutt

4

La systemctl restart systemd-journald.socket && systemctl restart rsyslogsolution n'a pas fonctionné pour moi sur Ubuntu 16.04.

Au lieu de cela, j'ai dû recréer /dev/logun lien symbolique vers /run/systemd/journal/dev-log:

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

— 11181
source

Oui, la liaison manuelle devrait également fonctionner. Mais c'est un peu difficile à retenir. Question: Sur Ubuntu systemd-journald.socketexiste- t- il en tant que service? Q2: restart rsyslogdc'était peut- être le problème? Peut-être que ça devrait être simplement start rsyslogd?

— Otheus

Q1: oui, il existe. Q2: il n'y a restartplus de commande, il y a serviceet /etc/init.d/rsyslog.

— 11181

Par restart rsyslogdje pensais qu'il était clair que je voulais dire systemctl restart rsyslogd. Ubuntu utilise-t-il toujours des scripts d'initialisation pour rsyslog?

— Otheus

@Otheus /etc/init.d/rsyslog stopsuivi de /etc/init.d/rsyslog startn'a pas aidé. Ni ne systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceSur mon système , il est à la fois /lib/systemd/system/rsyslog.serviceet /etc/init.d/rsyslog. Quoi qu'il en soit, je préfère ne pas passer plus de temps sur ce problème.

— 11181

0

Pour moi, cela a fini par être un problème avec la façon dont le module imuxsock utilisé dans rsyslog fonctionnait avec systemd.

Dans la documentation imuxsock, ils expliquent comment le module est censé fonctionner pour systemd. L'étape 1 était l'endroit où je voyais des problèmes:

Étape 1: Sélectionnez le nom du socket système

Si l'utilisateur n'a pas explicitement choisi de définir SysSock.Use = "off", le nom du socket d'écoute par défaut (aka, "socket du journal système" ou simplement "socket du système") est défini sur / dev / log. Sinon, si l'utilisateur a explicitement défini SysSock.Use = "off", rsyslog n'écoutera pas sur / dev / log OU aucun socket défini par le paramètre SysSock.Name et le reste de cette section ne s'applique pas.

Si l'utilisateur a spécifié sysSock.Name = "/ path / to / custom / socket" (et qu'il n'a pas explicitement défini SysSock.Use = "off"), le nom de socket d'écoute par défaut est remplacé par / path / to / custom / socket .

Sinon, si rsyslog s'exécute sous systemd ET / run / systemd / journal / syslog existe, (ET l'utilisateur n'a pas explicitement défini SysSock.Use = "off"), le nom de socket d'écoute par défaut est remplacé par / run / systemd / journal / syslog.

Le système aurait dû passer à l'étape 3 et changer le chemin par défaut en "/ run / systemd / journal / syslog" mais à la place il restait "/ var / log". Cela signifiait que le module imuxsock essaierait (et réussirait parfois) de créer un socket dans / dev / log où il devrait plutôt y avoir un lien symbolique créé par le systemd-journald-dev-log.socket. Dans le cas où il ne parviendrait pas à créer la vraie socket, le lien symbolique serait toujours supprimé.

Cette documentation était le résultat de ce problème signalé sur le github rsyslog. Si vous voulez sauter la discussion et passer directement aux changements, voir PR # 1 et PR # 2 respectivement.

Ma solution était de simplement configurer le module imuxsock pour utiliser le chemin systemd dans mon /etc/rsyslog.conf:

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

Cela semble avoir résolu mon problème et semble être une bonne solution ici car cela expliquerait pourquoi le lien symbolique pourrait à nouveau disparaître après l'avoir créé manuellement.

Si vous regardez sur votre système et que "/ run / systemd / journal / syslog" n'est pas présent, regardez le "syslog.socket" pour voir s'il démarre correctement car c'est ce qui est responsable de la création du socket.

systemctl status syslog.socket

Il se peut que votre version de rsyslog.service ne définisse pas syslog.service comme un alias qui est nécessaire car syslog.socket essaie d'activer ce service. Il est également possible que plusieurs services de journalisation tentent d'alias syslog.service, auquel cas le dernier à être activé l'emporte.

— Adam
source