Rsyslog не працює належним чином, він нічого не реєструє

Я запускаю сервер Debian і пару днів тому мій rsyslog почав вести себе дуже дивно, демон працює, але, схоже, нічого не робить. Багато людей користуються цією системою, але я єдиний з (законним) кореневим доступом.

Я використовую конфігурацію 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, сховатись у спробі знайти процеси приховування / порти та 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

[EDIT - інформація про напругу]

Страйс для мене виглядає нормально

[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

Повний журнал страз можна завантажити тут

Найімовірніше, це проблема власності на файл. rsyslog починає працювати як root, але потім відміняє привілеї та працює як syslog користувача (директива налаштування $ PrivDropToUser ).

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

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

Деякі версії rsyslog включають директиву $ omfileForceChown як вирішення для зовнішньої зміни власності на файл, але це не рекомендується. Рекомендований спосіб - правильно налаштувати право власності та дозволи. Більш детальну інформацію про це питання можна знайти за цим посиланням.

Якщо права доступу до файлів всі хороші і логротат правильно налаштований, наступним кроком буде ознайомлення з системними викликами 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!

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

Найсмішніше було, оскільки це був ramdisk, мені не було з кого копіювати в однокористувацькому режимі, так що я не знав, якими повинні бути дозволи та права власності! Дух.

Коротка історія з вашим новим місцезнаходженням:

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

Тепер Rsyslog зможе писати в / var / log, оскільки він працює як користувач 'syslog', група 'syslog'.