Używam serwera Debian i kilka dni temu mój rsyslog zaczął zachowywać się bardzo dziwnie, demon działa, ale wydaje się, że nic nie robi. Wiele osób korzysta z systemu, ale tylko ja mam (legalny) dostęp do roota.
Korzystam z domyślnej konfiguracji rsyslogd (jeśli uważasz, że to istotne, dołączę ją, ale jest to ta, która jest dołączona do pakietu).
Po obróceniu wszystkich plików dziennika pozostały puste:
# 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
Wszelkie próby wymuszenia zapisu dziennika nie mają żadnego skutku:
# logger hey
# ls -l /var/log/messages
-rw-r----- 1 root adm 0 Jun 26 13:03 /var/log/messages
Lsof pokazuje, że rsyslogd nie ma otwartych żadnych plików dziennika:
# 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
Byłem tak sfrustrowany, że nawet przeinstalowałem pakiet rsyslog, ale nadal nie chce niczego rejestrować:
# apt-get remove --purge rsyslog
# apt-get install rsyslog
Myślałem, że ktoś włamał się do systemu, więc uruchom rkhunter, chkrootkit i odkryj ukryte procesy / porty oraz nmap na zdalnym hoście, aby porównać z portami pokazanymi przez netstat. I wiem, że to nic nie znaczy, ale wszystko wygląda dobrze. System ma również zaporę ogniową iptables, która jest bardzo restrykcyjna w przypadku połączeń przychodzących / wychodzących.
Doprowadza mnie to do szału. Masz pojęcie, co się tutaj dzieje?
[EDYCJA - informacje o miejscu na dysku]
# 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
[EDYCJA - informacje o miejscu]
Strace wygląda dla mnie dobrze
[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
Pełny dziennik śledzenia można pobrać stąd
Odpowiedzi:
Najprawdopodobniej jest to problem z własnością pliku. rsyslog zaczyna działać jako root, ale następnie usuwa uprawnienia i działa jako syslog użytkownika (dyrektywa konfiguracyjna $ PrivDropToUser ).
Pliki syslog (auth.log, daemon.log itp.) początkowo są własnością syslog: adm, ale jeśli zmienisz własność na root (jak wynika z listy plików), to nie ważne, czy HUP (tj. przeładuj) rsyslog lub uruchom go ponownie, aby odmówić otwarcia tych plików z powodu braku uprawnień.
Jeśli zmiana własności nastąpiła po rotacji logów, sprawdź
create
opcję konfiguracji logrotate. Albo skonfigurować go tak jakcreate 0644 syslog adm
w/etc/logrotate.d/rsyslog
albo nawet lepiej zdefiniować ją globalnie na/etc/logrotate.conf
pominięciem trybu, właściciela i grupę, po prostu jak tocreate
(co jest domyślną konfigurację przy okazji), w którym sprawa będzie używane te same wartości w pliku. Zobaczman logrotate
szczegóły.Niektóre wersje rsyslog zawierają dyrektywę $ omfileForceChown jako obejście zewnętrznej zmiany własności pliku, ale nie jest to zalecane. Zalecanym sposobem jest prawidłowe skonfigurowanie własności i uprawnień. Więcej informacji na temat tego problemu można znaleźć pod tym linkiem.
źródło
Jeśli uprawnienia do plików są dobre, a logrotate jest poprawnie skonfigurowany, następnym krokiem będzie rzucić okiem na wywołania systemowe rsyslog.
Jak tylko moja literówka została naprawiona w tym pliku
/etc/rsyslog.d/50-default.conf
, syslog zaczął pisać do / var / log / syslog!źródło
Miałem ten problem, ponieważ mój / var / log rezydował na ramdysku, aby zmniejszyć zużycie mojego dysku SSD i chciałem przenieść go na dysk twardy, więc miałem więcej historii niż tylko bieżący rozruch.
Zabawne było to, że ponieważ był to ramdysk, nie miałem go do skopiowania w trybie pojedynczego użytkownika, więc nie wiedziałem, jakie powinny być uprawnienia i własność! Duh.
Krótka historia z nową lokalizacją:
Rsyslog będzie mógł teraz pisać do / var / log, ponieważ działa jako użytkownik „syslog”, grupa „syslog”.
źródło