Rsyslog가 제대로 작동하지 않습니다. 아무것도 기록하지 않습니다.

데비안 서버를 실행 중이며 며칠 전에 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을 찾으려면 unstat를 실행하여 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 정보]

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

— 빅터 헨리 케스
소스

로그 디스크가 가득 찼습니까?

— Jenny D

죄송합니다. 해당 정보를 추가하는 것을 잊었습니다. 질문을 업데이트하겠습니다. 그러나 여전히 로그를 작성하기에 충분한 공간이 있습니다.

— Victor Henriquez 2016 년

시도하고 strace -p <pid> 또는 strace에서 rsyslog를 수동으로 시작하고 무언가에 대해 불만이 있는지 확인하십시오

— manjiki

좋은 조언, 불행히도 나는 관련된 것을 찾을 수 없었습니다. 내가 잃어버린 것을 찾을 수 있도록 strace 로그로 질문을 업데이트했습니다. 정말 답답 해요.

— Victor Henriquez 2016 년

디버그 모드 (iirc 인 경우 -d)에서 수동으로 실행되므로 포크되지 않거나 strace의 팔로우 포크 옵션을 사용합니다. 내 나쁜, 미안

— manjiki 2016 년

답변:

아마도 파일 소유권 문제 일 것입니다. rsyslog는 루트로 실행되기 시작하지만 권한을 삭제하고 사용자 syslog (구성 지시문 $ PrivDropToUser ) 로 실행됩니다 .

syslog 파일 (auth.log, daemon.log 등)은 처음에 syslog : adm이 소유하지만 파일 목록에서 보이는 것처럼 소유권을 루트로 변경하면 rsyslog 또는 HUP (예 : 다시로드) 여부에 관계없이 권한 부족으로 인해 해당 파일을 열 수 없도록 다시 시작하십시오.

로그 회전 후 소유권 변경이 발생한 경우 로그 회전 create구성 옵션 을 확인하십시오 . 같은 방식 create 0644 syslog adm으로 구성 /etc/logrotate.d/rsyslog하거나 더 나은 방식으로 구성하고, /etc/logrotate.conf이와 같이 단순히 create기본 구성 인 모드, 소유자 및 그룹 을 생략하여 전역 적으로 정의하십시오. 이 경우 파일의 동일한 값이 사용됩니다. 자세한 man logrotate내용은 상담 하십시오.

일부 버전의 rsyslog에는 파일 소유권의 외부 변경에 대한 임시 해결책으로 지시문 $ omfileForceChown이 포함되어 있지만 권장되지는 않습니다. 권장되는 방법은 소유권과 권한을 올바르게 구성하는 것입니다. 이 문제에 대한 자세한 내용은 해당 링크를 참조하십시오.

— AAA
소스

이. 자세한 내용은 런치 패드의 rsyslogd 버그를 참조하십시오. bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/940030

— JustinC

당신은 락 맨, 나는이 문제를 발견 이틀 잃었다

— deFreitas

파일 권한이 모두 있고 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.confsyslog는 / var / log / syslog에 다시 쓰기 시작했습니다!

— 브라 테 브란트
소스

내 / var / log가 SSD의 마모를 줄이기 위해 램 디스크에 상주했기 때문에이 문제가 있었으며 HDD로 이동하여 현재 부팅보다 더 많은 기록을 가지고 싶었습니다.

재미있는 점은 램 디스크이기 때문에 단일 사용자 모드에서 복사 할 사본이 없으므로 권한과 소유권이 무엇인지 알지 못했습니다! 어.

새로운 위치와 짧은 이야기 :

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

Rsyslog는 이제 'syslog'사용자 그룹 'syslog'로 실행되므로 / var / log에 쓸 수 있습니다.

— 그렉 벨
소스