Este es un problema extraño.
Estaba probando los servicios chrony / ntp en una máquina virtual RHEL7 y estaba restableciendo su tiempo y el del host. Una vez que estuve satisfecho con él, lo comprobé /var/log/messages
y me di cuenta de que no había cambiado en mucho tiempo.
Ahora, no importa lo que haga, no se registra nada, excepto cuando reinicio el servicio rsyslog en sí; cuando lo hago me sale esto:
Apr 15 13:59:43 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2847" x-info="http://www.rsyslog.com"] exiting on signal 2.
Apr 15 13:59:59 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2853" x-info="http://www.rsyslog.com"] start
Apr 15 14:00:11 mymachine1 rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'
Intentando cosas como logger test
no iniciar sesión, nada más excepto los propios mensajes de rsyslog parece. Cuando ejecuto rsyslog manualmente con los -n -N1
argumentos que obtengo:
rsyslogd: version 7.4.2, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye
Parece que nada puede iniciar sesión en rsyslog por alguna razón. Y una segunda máquina virtual idéntica en el mismo host (que no pasó por el mismo círculo de inhabilitación repetida de ntp, que cambió la fecha y se reinició varias veces) con los mismos registros de archivos rsyslog.conf muy bien.
En este punto, la fecha / hora es correcta, la cronología está habilitada y ejecutándose, y la reinicié varias veces; después de 30 segundos de mensajes del kernel, nada más se registra nuevamente.
Pensamientos?
/etc/rsyslog.conf
y los/etc/rsyslog.d
directorios. Parece que no tiene nada configurado para enrutarse a un archivo de registro en particular. También puede intentar especificar un mensaje de syslog conEMERG
prioridad para ver si eso pasa. Ejemplo:logger -p EMERG not really an emergency
systemd
investigarlo , aparentemente esa es una opción para (a la que RHEL7 migró, IIRC) ¿Puede verificarjournalctl -b
si sus registros van al diario systemd?Respuestas:
No es una solución directa, pero permitiría un poco de depuración para ver qué sucede detrás de escena.
Idea # 1 - Registrador de depuración
Para empezar, cuando ejecuta sus
logger
comandos, puede hacerlos así, haciendo eco de los mensajes a STDERR.Idea # 2: validar su archivo de configuración
También puede intentar validar su archivo de configuración rsyslog:
Idea # 3 - Suba la depuración de rsyslogd
También intentaría habilitar la depuración del
rsyslogd
demonio para obtener más información.Confirmación de información de versión
Error confirmado y una solución alternativa
El OP lo envió como un error a Red Hat.
El error se caracterizó de la siguiente manera:
A lo que respondió uno de los desarrolladores:
fuente
En mi caso
systemctl restart systemd-journald
ayudó, porquefuente
Intente verificar rsyslog conf con: rsyslogd -f /etc/rsyslog.conf -N 1
Si todo está bien, intente reiniciar systemd-journald.socket con: systemctl restart systemd-journald.socket
puede usar el comando "logger" para verificar si rsyslog funciona o no: registrador "hola"
fuente