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?
Respuestas:
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:
reiniciar systemd-journald.socket:
systemctl restart systemd-journald.socket
luego reinicie rsyslogd
systemctl start rsyslogd
ACTUALIZACIÓN: creo que restart rsyslogdpodría volver a eliminar el socket si rsyslogdya se está ejecutando.
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
systemd-journald.socketexiste como un servicio? Q2: tal vez restart rsyslogdfue el problema? Tal vez debería ser simplemente start rsyslogd?
restartcomando, hay servicey /etc/init.d/rsyslog.
restart rsyslogdpensé que estaba claro que quise decir systemctl restart rsyslogd. ¿Ubuntu todavía usa scripts de inicio para rsyslog?
/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.
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
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.
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 .
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.