Rsyslog não está funcionando corretamente, ele não registra nada

Question

Eu estou rodando um servidor Debian e alguns dias atrás meu rsyslog começou a se comportar de maneira muito estranha, o daemon está rodando mas não parece fazer nada. Muitas pessoas usam o sistema, mas eu sou o único com acesso root (legal).

Estou usando a configuração padrão do rsyslogd (se você achar que é relevante, vou anexá-la, mas é a que vem com o pacote).

Depois de girar todos os arquivos de log, eles permaneceram vazios:

# 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

Qualquer tentativa de forçar uma gravação de log não tem nenhum efeito:

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

O Lsof mostra que o rsyslogd não possui arquivos de log abertos:

# 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

Eu estava tão frustrado que até mesmo reinstalar o pacote rsyslog, mas ainda se recusa a fazer qualquer coisa:

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

Eu achei que alguém havia hackeado o sistema, então execute rkhunter, chkrootkit, unhide em uma tentativa de encontrar hide processes / ports e nmap em um host remoto para comparar com as portas mostradas pelo netstat. E eu sei que isso não significa nada, mas tudo parece bem. O sistema também tem um firewall iptables que é muito restritivo com conexões de entrada / saída.

Isso está me deixando louco, alguma ideia do que está acontecendo aqui?

[EDITAR - informações sobre o espaço em 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

[EDIT - informações sobre strace]

Strace parece bem para mim

[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

O registro completo do strace pode ser baixado em aqui

    

Answer 1

O mais provável é que seja um problema de propriedade de arquivo. O rsyslog começa a ser executado como root, mas depois descarta privilégios e é executado como usuário syslog (diretiva de configuração $ PrivDropToUser ).

arquivos syslog (auth.log, daemon.log, etc.) inicialmente são de propriedade do syslog: adm, mas se você alterar a propriedade para root (como parece na sua lista de arquivos), então não importa se você HUP (ou seja, recarregar ) rsyslog ou reinicie-o, que será negado a abertura desses arquivos devido à falta de privilégios.

Se a mudança de propriedade ocorreu após a rotação do log, verifique a opção create da configuração do logrotate. Configure como create 0644 syslog adm em /etc/logrotate.d/rsyslog ou melhor, defina globalmente em /etc/logrotate.conf omitindo o modo, proprietário e grupo, simplesmente assim create (que é a configuração padrão a propósito), nesse caso os mesmos valores do arquivo serão usados. Consulte man logrotate para os detalhes completos.

Algumas versões do rsyslog incluem uma diretiva $ omfileForceChown como uma solução alternativa para a alteração externa da propriedade de arquivos, mas não é recomendado. A maneira recomendada é configurar corretamente a propriedade e as permissões. Mais informações sobre esse problema podem ser encontradas após esse link.

    

Answer 2

Eu tive esse problema porque meu / var / log estava residindo em um ramdisk para reduzir o desgaste no meu SSD e eu queria movê-lo para um HDD, então eu tinha mais histórico do que apenas a inicialização atual.

O engraçado era que, como era um disco virtual, eu não tinha um para copiar no modo de usuário único, então eu não sabia o que as permissões e propriedade deveriam ser! Duh.

História curta, com sua nova localização:

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

O Rsyslog agora poderá gravar em / var / log, já que é executado como o usuário do 'syslog', grupo 'syslog'.