Rsyslog no funciona correctamente, no registra nada

Estoy ejecutando un servidor Debian y hace un par de días mi rsyslog comenzó a comportarse de manera extraña, el demonio se está ejecutando pero no parece hacer nada. Muchas personas usan el sistema, pero yo soy el único con acceso raíz (legal).

Estoy usando la configuración predeterminada de rsyslogd (si crees que es relevante, la adjuntaré, pero es la que viene con el paquete).

Después de rotar todos los archivos de registro, permanecieron vacíos:

# ls -l /var/log/*.log
-rw-r--r-- 1 root root 0 Jun 27 00:25 /var/log/alternatives.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/auth.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/daemon.log
-rw-r--r-- 1 root root 0 Jun 27 00:25 /var/log/dpkg.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/kern.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/lpr.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/mail.log
-rw-r----- 1 root adm  0 Jun 26 13:03 /var/log/user.log

Cualquier intento de forzar una escritura de registro no tiene ningún efecto:

# logger hey
# ls -l /var/log/messages 
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/messages

Lsof muestra que rsyslogd no tiene ningún archivo de registro abierto:

# lsof -p 1855
COMMAND   PID USER   FD   TYPE     DEVICE SIZE/OFF       NODE NAME
rsyslogd 1855 root  cwd    DIR      202,0     4096          2 /
rsyslogd 1855 root  rtd    DIR      202,0     4096          2 /
rsyslogd 1855 root  txt    REG      202,0   342076      21649 /usr/sbin/rsyslogd
rsyslogd 1855 root  mem    REG      202,0    38556      32153 /lib/i386-linux-gnu/i686/cmov/libnss_nis-2.13.so
rsyslogd 1855 root  mem    REG      202,0    79728      32165 /lib/i386-linux-gnu/i686/cmov/libnsl-2.13.so
rsyslogd 1855 root  mem    REG      202,0    26456      32163 /lib/i386-linux-gnu/i686/cmov/libnss_compat-2.13.so
rsyslogd 1855 root  mem    REG      202,0   297500    1061058 /usr/lib/rsyslog/imuxsock.so
rsyslogd 1855 root  mem    REG      202,0    42628      32170 /lib/i386-linux-gnu/i686/cmov/libnss_files-2.13.so
rsyslogd 1855 root  mem    REG      202,0    22784    1061106 /usr/lib/rsyslog/imklog.so
rsyslogd 1855 root  mem    REG      202,0  1401000      32169 /lib/i386-linux-gnu/i686/cmov/libc-2.13.so
rsyslogd 1855 root  mem    REG      202,0    30684      32175 /lib/i386-linux-gnu/i686/cmov/librt-2.13.so
rsyslogd 1855 root  mem    REG      202,0     9844      32157 /lib/i386-linux-gnu/i686/cmov/libdl-2.13.so
rsyslogd 1855 root  mem    REG      202,0   117009      32154 /lib/i386-linux-gnu/i686/cmov/libpthread-2.13.so
rsyslogd 1855 root  mem    REG      202,0    79980      17746 /usr/lib/libz.so.1.2.3.4
rsyslogd 1855 root  mem    REG      202,0    18836    1061094 /usr/lib/rsyslog/lmnet.so
rsyslogd 1855 root  mem    REG      202,0   117960      31845 /lib/i386-linux-gnu/ld-2.13.so
rsyslogd 1855 root    0u  unix 0xebe8e800      0t0        640 /dev/log
rsyslogd 1855 root    3u  FIFO        0,5      0t0       2474 /dev/xconsole
rsyslogd 1855 root    4u  unix 0xebe8e400      0t0        645 /var/spool/postfix/dev/log
rsyslogd 1855 root    5r   REG        0,3        0 4026532176 /proc/kmsg

Estaba tan frustrado que incluso reinstalé el paquete rsyslog, pero todavía se niega a registrar cualquier cosa:

# apt-get remove --purge rsyslog
# apt-get install rsyslog

Pensé que alguien había pirateado el sistema, así que ejecute rkhunter, chkrootkit, oculte en un intento de encontrar procesos / puertos ocultos y nmap en un host remoto para comparar con los puertos mostrados por netstat. Y sé que esto no significa nada, pero todo parece estar bien. El sistema también tiene un firewall de iptables que es muy restrictivo con las conexiones entrantes / salientes.

Esto me está volviendo loco, ¿alguna idea de lo que está pasando aquí?

[EDITAR - información de espacio en disco]

# df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                 24G   22G  629M  98% /
/dev/root              24G   22G  629M  98% /
devtmpfs               10M  112K  9.9M   2% /dev
tmpfs                  76M   48K   76M   1% /run
tmpfs                 5.0M     0  5.0M   0% /run/lock
tmpfs                 151M   40K  151M   1% /tmp
tmpfs                 151M     0  151M   0% /run/shm

[EDITAR - información de strace]

Strace se ve bien para mí

[pid 28824] access("/var/log/auth.log", F_OK) = 0
[pid 28824] access("/var/log/syslog", F_OK) = 0
[pid 28824] access("/var/log/daemon.log", F_OK) = 0
[pid 28824] access("/var/log/kern.log", F_OK) = 0
[pid 28824] access("/var/log/lpr.log", F_OK) = 0
[pid 28824] access("/var/log/mail.log", F_OK) = 0
[pid 28824] access("/var/log/user.log", F_OK) = 0
[pid 28824] access("/var/log/mail.info", F_OK) = 0
[pid 28824] access("/var/log/mail.warn", F_OK) = 0
[pid 28824] access("/var/log/mail.err", F_OK) = 0
[pid 28824] access("/var/log/news/news.crit", F_OK) = 0
[pid 28824] access("/var/log/news/news.err", F_OK) = 0
[pid 28824] access("/var/log/news/news.notice", F_OK) = 0
[pid 28824] access("/var/log/debug", F_OK) = 0
[pid 28824] access("/var/log/messages", F_OK) = 0

El registro de strace completo se puede descargar desde aquí

rsyslog

— Victor Henriquez
fuente

¿Está lleno el disco de registro?

— Jenny D

Oh lo siento, olvidé agregar esa información, actualizaré la pregunta. Pero todavía hay suficiente espacio para escribir registros.

— Victor Henriquez

intente strace -p <pid> o inicie rsyslog manualmente debajo de strace y compruebe si se queja de algo

— manjiki

Buen consejo, desafortunadamente no he podido encontrar nada relevante. He actualizado la pregunta con el registro de strace, en caso de que puedas encontrar algo que me falta. Estoy realmente frustrado

— Victor Henriquez

se ejecuta manualmente en modo de depuración (-d si iirc), para que no se bifurque, o use la opción de bifurcación de seguimiento de strace. Mi mal, lo siento.

— manjiki

Respuestas:

Lo más probable es que sea un problema de propiedad de archivos. rsyslog comienza a ejecutarse como root pero luego elimina privilegios y se ejecuta como syslog de usuario (directiva de configuración $ PrivDropToUser ).

Los archivos syslog (auth.log, daemon.log, etc.) inicialmente son propiedad de syslog: adm pero si cambia la propiedad a root (como parece de su lista de archivos), no importa si HUP (es decir, recargar) rsyslog o reinícielo, se le negará la apertura de esos archivos debido a la falta de privilegios.

Si el cambio de propiedad ocurrió después de la rotación de registros, marque la createopción de su configuración de rotación de registros . O configúrelo como create 0644 syslog admen /etc/logrotate.d/rsyslogo incluso mejor, defínalo globalmente al /etc/logrotate.confomitir el modo, el propietario y el grupo, simplemente así create(por cierto, que es la configuración predeterminada), en cuyo caso se utilizarán los mismos valores del archivo. Consulte man logrotatepor los detalles completos.

Algunas versiones de rsyslog incluyen una directiva $ omfileForceChown como solución para el cambio externo de la propiedad del archivo, pero no se recomienda. La forma recomendada es configurar correctamente la propiedad y los permisos. Puede encontrar más información sobre este tema siguiendo ese enlace.

— AAA
fuente

Esta. Para más discusión y detalles, vea el error rsyslogd en el launchpad: bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/940030

— JustinC

Eres un hombre

— genial

Tuve este problema porque mi / var / log residía en un disco RAM para reducir el desgaste de mi SSD y quería moverlo a un HDD, así que tenía más historial que solo el arranque actual.

Lo curioso fue que, dado que era un disco RAM, no tenía uno para copiar en modo de usuario único, ¡así que no sabía cuáles debían ser los permisos y la propiedad! Duh

Breve historia, con su nueva ubicación:

chmod 770 /var/log
chgrp syslog /var/log
initctl restart rsyslog

Rsyslog ahora podrá escribir en / var / log ya que se ejecuta como el usuario 'syslog', grupo 'syslog'.

— Greg Bell
fuente

Si todos los permisos de archivo son buenos y logrotate está configurado correctamente, su próximo paso será echar un vistazo a las llamadas al sistema rsyslog.

# find the start command 
me@d2-slprod02:~$ sudo systemctl status rsyslog
● rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2019-06-21 10:04:43 CEST; 2h 26min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 18753 (rsyslogd)
    Tasks: 4
   Memory: 1.4M
      CPU: 291ms
   CGroup: /system.slice/rsyslog.service
           └─18753 /usr/sbin/rsyslogd -n

 # let's have a look at syscalls.
 sudo strace /usr/sbin/rsyslogd -n
 ...
 write(2, "rsyslogd: error during parsing f"..., 206rsyslogd: error during parsing file /etc/rsyslog.d/50-default.conf, on or before line 8: warnings occured in file '/etc/rsyslog.d/50-default.conf' around line 8 [v8.16.0 try http://www.rsyslog.com/e/2207 ]
 ...

¡Tan pronto como mi error tipográfico se corrigió en este archivo /etc/rsyslog.d/50-default.conf, syslog comenzó a escribir en / var / log / syslog nuevamente!

— Bjarte Brandt
fuente