Я использую сервер 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]
Стрейс мне подходит
[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 как обходной путь для внешней смены владельца файла, но это не рекомендуется. Рекомендуемый способ - правильно настроить права собственности и разрешения. Дополнительную информацию об этой проблеме можно найти по этой ссылке.
Если все права доступа к файлам в порядке и 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!
У меня была эта проблема, потому что мой / var / log находился на ramdisk, чтобы уменьшить износ моего SSD, и я хотел переместить его на жесткий диск, чтобы у меня было больше истории, чем просто текущая загрузка.
Забавно было то, что, поскольку это был ramdisk, у меня не было ни одного для копирования в однопользовательском режиме, поэтому я не знал, какими должны быть разрешения и права собственности! Ага.
Краткая история с вашим новым местоположением:
chmod 770 /var/log
chgrp syslog /var/log
initctl restart rsyslog
Rsyslog теперь сможет писать в / var / log, так как он работает как пользователь syslog, группа syslog.
Сегодня возникли проблемы с разрешениями - в моем случае это было отключение SELINUX. Rsyslog отправлялся на выделенное монтирование и запрещал разрешения.
Вот как я решил это:
ls -Zd /var/log
drwxr-xr-x root root system_u:object_r:var_log_t:s0 /var/log
Взяв эту информацию, я применил изменения к расположению rsyslog:
chcon -tR var_log_t /new/directory
Перезапустил rsyslog и сразу увидел успешный запуск. Связал другие серверы RHEL с сервером журналов и наблюдал, как другие серверы RHEL сразу же начали подключаться к нему. обратите внимание, каталог работал нормально всего с 600 разрешениями.