Rsyslog funktioniert nicht richtig, es protokolliert nichts

Ich verwende einen Debian-Server und vor ein paar Tagen hat sich mein rsyslog sehr seltsam verhalten. Der Daemon wird ausgeführt, scheint aber nichts zu tun. Viele Leute benutzen das System, aber ich bin der einzige mit (legalem) Root-Zugriff.

Ich verwende die Standardkonfiguration von rsyslogd (wenn Sie dies für relevant halten, werde ich sie anhängen, aber es ist diejenige, die mit dem Paket geliefert wird).

Nachdem ich alle Protokolldateien gedreht habe, sind sie leer geblieben:

# 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

Jeder Versuch, ein Protokollschreiben zu erzwingen, hat keine Auswirkung:

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

Lsof zeigt, dass in rsyslogd keine Protokolldateien geöffnet sind:

# 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

Ich war so frustriert, dass ich sogar das rsyslog-Paket neu installiert habe, aber es weigert sich immer noch, irgendetwas zu protokollieren:

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

Ich dachte, jemand hätte das System gehackt, also führen Sie rkhunter, chkrootkit, und blenden Sie es aus, um versteckte Prozesse / Ports und nmap auf einem Remote-Host zu finden, um sie mit den von netstat angezeigten Ports zu vergleichen. Und ich weiß, das hat nichts zu bedeuten, aber alles sieht in Ordnung aus. Das System verfügt außerdem über eine iptables-Firewall, die bei eingehenden / ausgehenden Verbindungen sehr restriktiv ist.

Das macht mich verrückt, weißt du was hier los ist?

[EDIT - Speicherplatzinfo]

# 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 - strace info]

Strace sieht für mich gut aus

[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

Das vollständige Strace-Protokoll kann hier heruntergeladen werden

rsyslog

— Victor Henriquez
quelle

Ist die Protokolldiskette voll?

— Jenny D

Oh, Entschuldigung, ich habe vergessen, diese Informationen hinzuzufügen. Ich werde die Frage aktualisieren. Es ist jedoch noch genügend Platz zum Schreiben von Protokollen vorhanden.

— Victor Henriquez

versuchen Sie, -p <pid> zu strace oder starten Sie rsyslog manuell unter strace und prüfen Sie, ob es sich über etwas beschwert

— manjiki

Guter Rat, leider konnte ich nichts Relevantes finden. Ich habe die Frage mit dem Strace-Protokoll aktualisiert, nur für den Fall, dass Sie etwas finden, das mir fehlt. Ich bin wirklich frustriert.

— Victor Henriquez

Führen Sie den Debug-Modus manuell aus (-d, wenn iirc), damit er nicht gegabelt wird, oder verwenden Sie die Option zum Verfolgen der Gabeln von strace. Es tut mir leid.

— Manjiki

Antworten:

Höchstwahrscheinlich handelt es sich um ein Problem mit dem Dateibesitz. rsyslog wird als Root ausgeführt, löscht jedoch die Berechtigungen und wird als Benutzer-Syslog ausgeführt (Konfigurationsanweisung $ PrivDropToUser ).

Syslog-Dateien (auth.log, daemon.log usw.) gehören anfangs syslog: adm. Wenn Sie jedoch den Besitz in root ändern (wie aus Ihrer Dateiliste hervorgeht), spielt es keine Rolle, ob Sie rsyslog oder HUP (dh neu laden) Starten Sie es neu, damit das Öffnen dieser Dateien aufgrund fehlender Berechtigungen verweigert wird.

Wenn der Eigentümerwechsel nach der Protokollrotation stattgefunden hat, createaktivieren Sie die Option Ihrer Protokollrotationskonfiguration. Konfigurieren Sie es entweder wie create 0644 syslog admin /etc/logrotate.d/rsyslogoder noch besser, definieren Sie es global, /etc/logrotate.confindem Sie den Modus, den Eigentümer und die Gruppe einfach so weglassen create(dies ist übrigens die Standardkonfiguration). In diesem Fall werden die gleichen Werte der Datei verwendet. Konsultieren Sie man logrotatefür die vollständigen Details.

Einige Versionen von rsyslog enthalten eine Direktive $ omfileForceChown als Problemumgehung für die externe Änderung des Dateieigentums, dies wird jedoch nicht empfohlen. Die empfohlene Methode besteht darin, den Besitz und die Berechtigungen ordnungsgemäß zu konfigurieren. Weitere Informationen zu diesem Problem finden Sie unter diesem Link.

— AAA
quelle

Dies. Weitere Diskussionen und Details finden Sie im rsyslogd-Fehler auf dem Launchpad: bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/940030

— JustinC

— Rockmann

Ich hatte dieses Problem, weil sich mein / var / log auf einer Ramdisk befand, um den Verschleiß meiner SSD zu verringern, und ich wollte es auf eine Festplatte verschieben, damit ich mehr Verlauf als nur den aktuellen Start hatte.

Das Komische war, da es sich um eine Ramdisk handelte, hatte ich keine, von der ich im Einzelbenutzermodus kopieren konnte, also wusste ich nicht, wie die Berechtigungen und der Besitz sein sollten! Duh.

Kurzgeschichte mit Ihrem neuen Standort:

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

Rsyslog kann jetzt in / var / log schreiben, da es als Benutzer 'syslog', Gruppe 'syslog' ausgeführt wird.

— Greg Bell
quelle

Wenn alle Dateiberechtigungen gut sind und logrotate korrekt konfiguriert ist, müssen Sie sich als Nächstes die Systemaufrufe von rsyslog ansehen.

# 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 ]
 ...

Sobald mein Tippfehler in dieser Datei behoben war /etc/rsyslog.d/50-default.conf, begann syslog wieder in / var / log / syslog zu schreiben!

— Bjarte Brandt
quelle