Rsyslog 无法正常工作，它不记录任何内容

Question

我正在运行 Debian 服务器，几天前我的 rsyslog 开始表现得很奇怪，守护进程正在运行但它似乎没有做任何事情。许多人使用该系统，但我是唯一拥有（合法）root 访问权限的人。

我正在使用默认的 rsyslogd 配置（如果您认为相关，我会附上它，但它是随包提供的配置）。

在我轮换所有日志文件后，它们仍然是空的：

# 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

任何强制写入日志的尝试都没有任何效果：

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

lsof 显示 rsyslogd 没有打开任何日志文件：

# 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

我很沮丧，甚至重新安装了 rsyslog 包，但它仍然拒绝记录任何内容：

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

我以为有人入侵了系统，因此运行 rkhunter、chkrootkit、unhide 以尝试在远程主机中找到隐藏进程/端口和 nmap 以与 netstat 显示的端口进行比较。我知道这并不意味着什么，但一切看起来都很好。该系统还有一个 iptables 防火墙，它对传入/传出连接非常严格。

这让我发疯，知道这里发生了什么吗？

[编辑 - 磁盘空间信息]

# 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

[编辑 - 跟踪信息]

Strace 对我来说没问题

[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

完整的 strace 日志可以从这里下载

Answer 1

很可能是文件所有权问题。rsyslog 开始以 root 身份运行，但随后放弃特权并以用户 syslog 身份运行（配置指令$PrivDropToUser）。

syslog 文件（auth.log、daemon.log 等）最初由 syslog:adm 所有，但是如果您将所有权更改为 root（从您的文件列表中可以看出），那么无论您是 HUP（即重新加载）rsyslog 还是重新启动它，由于缺乏权限，它将被拒绝打开这些文件。

如果在日志轮换后发生所有权更改，请检查create您的 logrotate 配置选项。要么像create 0644 syslog admin一样配置它，/etc/logrotate.d/rsyslog要么更好，在/etc/logrotate.conf省略模式、所有者和组的情况下全局定义它，就像这样create（顺便说一下，这是默认配置），在这种情况下，将使用文件的相同值。man logrotate详情请咨询。

某些版本的rsyslog包含指令$omfileForceChown作为外部更改文件所有权的解决方法，但不建议这样做。推荐的方法是正确配置所有权和权限。可以在该链接后找到有关此问题的更多信息。