Rsyslog не работает должным образом, он ничего не регистрирует

Я использую сервер 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, который очень ограничивает входящие / исходящие соединения.

Это сводит меня с ума, есть идеи, что здесь происходит?

[EDIT - информация о дисковом пространстве]

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

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 можно скачать здесь

Скорее всего, это проблема владения файлами. rsyslog запускается от имени пользователя root, но затем отбрасывает привилегии и запускается от имени пользователя syslog (директива конфигурации $ PrivDropToUser ).

Файлы syslog (auth.log, daemon.log и т. д.) изначально принадлежат syslog: adm, но если вы смените владельца на root (как это видно из списка файлов), то не имеет значения, используете ли вы HUP (т.е. перезагружаете) rsyslog или перезапустите его, чтобы запретить открывать эти файлы из-за отсутствия привилегий.

Если смена владельца произошла после ротации журнала, то проверьте createопцию конфигурации logrotate. Либо настройте его как create 0644 syslog admв, /etc/logrotate.d/rsyslogили даже лучше, определите его глобально, /etc/logrotate.confопуская режим, владельца и группу, просто так create(как, кстати, это конфигурация по умолчанию), и в этом случае будут использоваться те же значения файла. Проконсультируйтесь man logrotateдля получения полной информации.

Некоторые версии rsyslog включают директиву $ omfileForceChown в качестве обходного пути для внешнего изменения владельца файла, но это не рекомендуется. Рекомендуемый способ - правильно настроить владельца и разрешения. Дополнительную информацию об этой проблеме можно найти по этой ссылке.

У меня была эта проблема, потому что мой / var / log находился на виртуальном диске для уменьшения износа моего SSD, и я хотел перенести его на жесткий диск, чтобы у меня было больше истории, чем просто текущей загрузки.

Забавно то, что, поскольку это был виртуальный диск, мне не нужно было копировать его в однопользовательском режиме, поэтому я не знал, какими должны быть разрешения и владелец! Duh.

Короткая история с вашим новым местоположением:

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

Rsyslog теперь сможет записывать в / var / log, так как он запускается как пользователь 'syslog', группа 'syslog'.

Если права доступа к файлам хороши, а logrotate настроен правильно, следующим шагом будет просмотр системных вызовов 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 ]
 ...

Как только моя опечатка была исправлена ​​в этом файле /etc/rsyslog.d/50-default.conf, syslog снова начал писать в / var / log / syslog!