¿Cómo restauro `/ dev / log` en systemd + rsyslog host?

10

En RHEL7, systemd-journaldasume muchas de las responsabilidades de lo que una vez hizo rsyslogd. Ya sea por error o conflicto entre estos dos demonios, a veces /dev/logdesaparecerá. Como resultado, los programas que dependen de la syslog(3)llamada no funcionarán correctamente, incluyendo, por ejemplo, logger. ¿Cómo puedo restaurar el /dev/logzócalo?

systemd-journald rsyslogd Oteo
fuente

Respuestas:

13

Preguntando y respondiendo mi propia pregunta porque Google no fue muy útil en este caso.

Normalmente, con rsyslogd, el imuxsockmódulo creará el /dev/logsocket por sí solo, desvinculando la entrada anterior antes de crearlo. Cuando rsyslogdse detiene (posiblemente porque el reinicio falla debido a una configuración defectuosa), rsyslogd elimina /dev/log .

Sin embargo, RHEL7se espera que el rsyslog suministrado se use junto con systemd, y el imuxsockmódulo realmente se abrirá y eliminará el /run/systemd/journal/syslogsocket. Mientras tanto, el /dev/logdispositivo es creado por el archivo de servicio del sistema systemd-journald.socketque se dispara journald.

Aparentemente, ya sea que se use o no un $imjournalmódulo, lo siguiente funciona.

En suma, si /dev/logdesaparece:

  1. reiniciar systemd-journald.socket:

    systemctl restart systemd-journald.socket

  2. luego reinicie rsyslogd

    systemctl start rsyslogd

ACTUALIZACIÓN: creo que restart rsyslogdpodría volver a eliminar el socket si rsyslogdya se está ejecutando.

Oteo
fuente
2
¡Muchas gracias por esto! Perdí varias horas rastreando por qué el registro no funcionaba para un servicio. Finalmente lo rastreé hasta el / dev / missing, lo que me llevó a su solución.
Chad Huneycutt
4

La systemctl restart systemd-journald.socket && systemctl restart rsyslogsolución no funcionó para mí en Ubuntu 16.04.

En cambio, tuve que recrear /dev/logcomo un enlace simbólico para /run/systemd/journal/dev-log:

ln -s /run/systemd/journal/dev-log /dev/log
11181
fuente
Sí, la vinculación manual también debería funcionar. Pero es un poco difícil de recordar. Pregunta: ¿En Ubuntu systemd-journald.socketexiste como un servicio? Q2: tal vez restart rsyslogdfue el problema? Tal vez debería ser simplemente start rsyslogd?
Oteo
Q1: sí, existe. P2: ya no hay restartcomando, hay servicey /etc/init.d/rsyslog.
11181
Por restart rsyslogdpensé que estaba claro que quise decir systemctl restart rsyslogd. ¿Ubuntu todavía usa scripts de inicio para rsyslog?
Oteo
@Otheus /etc/init.d/rsyslog stopseguido por /etc/init.d/rsyslog startno ayudó. Tampoco systemctl stop syslog.socket rsyslog.service && systemctl start syslog.socket rsyslog.serviceen mi sistema hay ambos /lib/systemd/system/rsyslog.servicey /etc/init.d/rsyslog. De todos modos, prefiero no dedicar más tiempo a este problema.
11181
0

Para mí, esto terminó siendo un problema con la forma en que el módulo imuxsock utilizado en rsyslog funcionaba con systemd.

En la documentación de imuxsock, explican cómo se supone que el módulo debe funcionar para systemd. El paso 1 era donde estaba viendo problemas:

Paso 1: seleccione el nombre del zócalo del sistema

  1. Si el usuario no ha elegido explícitamente establecer SysSock.Use = "off", el nombre del socket de escucha predeterminado (también conocido como "socket de registro del sistema" o simplemente "socket del sistema") se establece en / dev / log. De lo contrario, si el usuario ha establecido explícitamente SysSock.Use = "off", entonces rsyslog no escuchará en / dev / log O cualquier socket definido por el parámetro SysSock.Name y el resto de esta sección no se aplica.

  2. Si el usuario ha especificado sysSock.Name = "/ path / to / custom / socket" (y no ha establecido SysSock.Use = "off" explícitamente), el nombre del socket de escucha predeterminado se sobrescribe con / path / to / custom / socket .

  3. De lo contrario, si rsyslog se ejecuta en systemd AND / run / systemd / journal / syslog existe (Y el usuario no ha establecido explícitamente SysSock.Use = "off"), el nombre del socket de escucha predeterminado se sobrescribe con / run / systemd / journal / syslog.

El sistema debería haber caído en el Paso 3 y cambiar la ruta predeterminada para que sea "/ run / systemd / journal / syslog", pero en su lugar permanecía "/ var / log". Esto significaba que el módulo imuxsock intentaría (y tendría éxito a veces) crear un socket en / dev / log donde debería haber un enlace simbólico creado por systemd-journald-dev-log.socket. En el caso de que no pudiera crear el socket real, el enlace simbólico aún se eliminaría.

Esa documentación fue el resultado de este problema informado en el rsyslog github. Si desea omitir la discusión y saltar directamente a los cambios, vea PR # 1 y PR # 2 respectivamente.

Mi solución fue simplemente configurar el módulo imuxsock para usar la ruta systemd en mi /etc/rsyslog.conf:

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

Esto parece haber solucionado mi problema y parece una buena solución aquí, ya que explicaría por qué el enlace simbólico podría desaparecer nuevamente después de crearlo manualmente.

Si observa su sistema y "/ run / systemd / journal / syslog" no está presente, mire el "syslog.socket" para ver si se está iniciando correctamente, ya que eso es lo que es responsable de crear el socket.

systemctl status syslog.socket

Puede ser que su versión de rsyslog.service no defina syslog.service como un alias que se necesita cuando syslog.socket intenta activar ese servicio. También es posible que múltiples servicios de registro intenten alias syslog.service, en cuyo caso el último en habilitarse gana.

Adán
fuente