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.
$ logger -s "hi"
saml: hi
Idea # 2: validar su archivo de configuración
También puede intentar validar su archivo de configuración rsyslog:
$ sudo rsyslogd -N6 | head -10
rsyslogd: version 7.2.6, config validation run (level 6), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.
6921.173842409:7f8b11df2780: rsyslogd 7.2.6 startup, module path '', cwd:/root
6921.175241008:7f8b11df2780: caller requested object 'net', not found (iRet -3003)
6921.175261977:7f8b11df2780: Requested to load module 'lmnet'
6921.175272711:7f8b11df2780: loading module '/lib64/rsyslog/lmnet.so'
6921.175505384:7f8b11df2780: module lmnet of type 2 being loaded (keepType=0).
6921.175520208:7f8b11df2780: entry point 'isCompatibleWithFeature' not present in module
6921.175528413:7f8b11df2780: entry point 'setModCnf' not present in module
6921.175535294:7f8b11df2780: entry point 'getModCnfName' not present in module
6921.175541502:7f8b11df2780: entry point 'beginCnfLoad' not present in module
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.
$ sudo -i
$ export RSYSLOG_DEBUGLOG="/tmp/debuglog"
$ export RSYSLOG_DEBUG="Debug"
$ service rsyslog stop
$ rsyslogd -d | head -10
7160.005597645:7fae096a3780: rsyslogd 7.2.6 startup, module path '', cwd:/root
7160.005872662:7fae096a3780: caller requested object 'net', not found (iRet -3003)
7160.005895004:7fae096a3780: Requested to load module 'lmnet'
7160.005906331:7fae096a3780: loading module '/lib64/rsyslog/lmnet.so'
7160.006023505:7fae096a3780: module lmnet of type 2 being loaded (keepType=0).
7160.006030872:7fae096a3780: entry point 'isCompatibleWithFeature' not present in module
7160.006033780:7fae096a3780: entry point 'setModCnf' not present in module
7160.006036209:7fae096a3780: entry point 'getModCnfName' not present in module
7160.006038359:7fae096a3780: entry point 'beginCnfLoad' not present in module
...
...
7160.006063913:7fae096a3780: rsyslog runtime initialized, version 7.2.6, current users 1
7160.006102179:7fae096a3780: source file syslogd.c requested reference for module 'lmnet', reference count now 2
7160.006113657:7fae096a3780: GenerateLocalHostName uses 'greeneggs'
Confirmación de información de versión
$ rsyslogd -version
rsyslogd 7.2.6, compiled with:
FEATURE_REGEXP: Yes
FEATURE_LARGEFILE: No
GSSAPI Kerberos 5 support: Yes
FEATURE_DEBUG (debug build, slow code): No
32bit Atomic operations supported: Yes
64bit Atomic operations supported: Yes
Runtime Instrumentation (slow code): No
uuid support: Yes
See http://www.rsyslog.com for more information.
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:
Efectivamente, cuando configuré el tiempo del host, la VM tuvo el mismo tiempo incorrecto que el host. Fue entonces cuando noté que / var / log / messages ya no se actualizaba.
Resulta que nada más que reiniciar el servicio rsyslog se registra en los archivos en ese momento. Si lo hago, esto se registra:
---
Apr 15 16:39:39 rhel7time-dev rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'
Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="574" x-info="http://www.rsyslog.com"] exiting on signal 15.
Apr 15 16:39:39 rhel7time-dev rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2117" x-info="http://www.rsyslog.com"] start
---
De lo contrario, no se registra nada en el archivo, incluido el registrador.
Si comento $ OmitLocalLogging en rsyslog.conf, se reanuda el registro de archivos (tenga en cuenta que hasta ese momento no había cambiado rsyslog.conf).
Iniciar sesión en el diario no se ve afectado por todo esto. journalctl -b muestra el registro, incluido todo lo enviado por el registrador.
A lo que respondió uno de los desarrolladores:
Cuando se produce este problema, puede eliminar /var/lib/rsyslog/imjournal.state
y reiniciar el demonio como solución alternativa.
rsyslog no maneja la fecha directamente sino solo a través de la API systemd. Verifiqué el código en el diario hace un tiempo y esto parece un problema en systemd.
Para referencia, consulte: https://github.com/rsyslog/rsyslog/issues/43
/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