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í
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
create
opción de su configuración de rotación de registros . O configúrelo comocreate 0644 syslog adm
en/etc/logrotate.d/rsyslog
o incluso mejor, defínalo globalmente al/etc/logrotate.conf
omitir 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. Consulteman logrotate
por 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.
fuente
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:
Rsyslog ahora podrá escribir en / var / log ya que se ejecuta como el usuario 'syslog', grupo 'syslog'.
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.
¡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!fuente