Rsyslog non funziona correttamente, non registra nulla

Sto eseguendo un server Debian e un paio di giorni fa il mio rsyslog ha iniziato a comportarsi in modo molto strano, il demone è in esecuzione ma non sembra fare nulla. Molte persone usano il sistema ma io sono l'unico con accesso (legale) root.

Sto usando la configurazione predefinita di rsyslogd (se pensi che sia pertinente, la allego, ma è quella fornita con il pacchetto).

Dopo aver ruotato tutti i file di registro, sono rimasti vuoti:

# 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

Qualsiasi tentativo di forzare una scrittura del registro non ha alcun effetto:

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

Lsof mostra che rsyslogd non ha alcun file di registro aperto:

# 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

Ero così frustrato che ho anche reinstallato il pacchetto rsyslog, ma si rifiuta ancora di registrare nulla:

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

Pensavo che qualcuno avesse violato il sistema, quindi esegui rkhunter, chkrootkit, scopri nel tentativo di trovare processi / porte nascosti e nmap in un host remoto per confrontarli con le porte mostrate da netstat. E so che questo non significa nulla, ma tutto sembra a posto. Il sistema ha anche un firewall iptables che è molto restrittivo con le connessioni in entrata / uscita.

Questo mi sta facendo impazzire, hai idea di cosa sta succedendo qui?

[EDIT - informazioni sullo spazio su 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 - informazioni strace]

Strace mi sta bene

[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

Il registro di strace completo può essere scaricato da qui

rsyslog

— Victor Henriquez
fonte

Il disco di registro è pieno?

— Jenny D,

Oh scusa, ho dimenticato di aggiungere quelle informazioni, aggiornerò la domanda. Ma c'è ancora abbastanza spazio per scrivere i log.

— Victor Henriquez,

prova e straccia -p <pid> o avvia rsyslog manualmente sotto strace e controlla se si lamenta di qualcosa

— manjiki

Un buon consiglio, purtroppo non sono stato in grado di trovare nulla di rilevante. Ho aggiornato la domanda con il registro strace, nel caso in cui riesci a trovare qualcosa che mi manca. Sono davvero frustrato.

— Victor Henriquez,

esegui manualmente in modalità debug (-d se iirc), quindi non si biforcherà, o usa l'opzione follow forks di strace. Mio male, scusa.

— manjiki,

Risposte:

Molto probabilmente si tratta di un problema di proprietà dei file. rsyslog inizia a funzionare come root ma poi rilascia i privilegi e viene eseguito come syslog dell'utente (direttiva di configurazione $ PrivDropToUser ).

I file syslog (auth.log, daemon.log, ecc.) inizialmente sono di proprietà di syslog: adm ma se si cambia la proprietà in root (come appare dall'elenco dei file), non importa se si HUP (es. ricarica) rsyslog o riavviarlo, che gli verrà negato di aprire quei file a causa della mancanza di privilegi.

Se il cambio di proprietà è avvenuto dopo la rotazione del registro, selezionare l' createopzione della configurazione di logrotate. Configuralo come create 0644 syslog admin /etc/logrotate.d/rsyslogo anche meglio, definilo globalmente /etc/logrotate.confomettendo la modalità, il proprietario e il gruppo, semplicemente in questo modo create(che è la configurazione predefinita tra l'altro), nel qual caso verranno utilizzati gli stessi valori del file. Consultare man logrotateper i dettagli completi.

Alcune versioni di rsyslog includono una direttiva $ omfileForceChown come soluzione alternativa per la modifica esterna della proprietà del file, ma non è consigliata. Il modo consigliato è configurare correttamente la proprietà e le autorizzazioni. Ulteriori informazioni su questo problema possono essere trovate seguendo quel link.

— AAA
fonte

Questo. Per ulteriori discussioni e dettagli, vedere il bug rsyslogd sul launchpad: bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/940030

— JustinC

— Amico

Ho avuto questo problema perché il mio / var / log risiedeva su un ramdisk per ridurre l'usura sul mio SSD e volevo spostarlo su un HDD, quindi avevo più cronologia del solo avvio corrente.

La cosa divertente era che, dato che era un ramdisk, non ne avevo uno da copiare in modalità utente singolo, quindi non sapevo quali fossero le autorizzazioni e la proprietà! Duh.

Breve storia, con la tua nuova posizione:

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

Ora Rsyslog sarà in grado di scrivere su / var / log poiché viene eseguito come utente "syslog", gruppo "syslog".

— Greg Bell
fonte

Se le autorizzazioni per i file sono tutte valide e logrotate è configurato correttamente, il passo successivo sarà quello di dare un'occhiata alle chiamate di 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 ]
 ...

Non appena il mio errore di battitura è stato corretto in questo file /etc/rsyslog.d/50-default.conf, syslog ha iniziato a scrivere di nuovo su / var / log / syslog!

— Bjarte Brandt
fonte