박주연 2019-03

1. rsyslogd 와는 관련이 없습니다.
의심스럽다면 로그 저장하는 장소를 변경해서 원격을 로컬로 바꾼후 확인해 보세요
똑같은 로그가 계속 저장 될겁니다.
로그 일부만 올려서 추측이지만
로그생성빈도나 시간을 봤을때 디스크 풀이 생길정도면 로그저장되는곳이 너무 작은 용량 같네요
개인적으로 로그 보관할때 원격에 저장하더라도 로컬에 일정정도 보관하도록 설치합니다.

2. 시스템버그?
시스템버그는 아닌거 같네요
만드신 프로그램, 스크립트 점검해 보세요

online9 2019-03

감사합니다
퇴근길에 itx에서 차분히 생각해보니
rsyslogd설정이 잘못된 것으로 판단했습니다
was서버에 설정이 자기 자신으로 또 보내도록
되어 있어서 로컬에 기록하고 또 자신에게 보내서
또 쓰고 또보내고 하는거 같습니다
솔루션업체에서 제품설치하고 rsyslogd로 여러 서버의
로그를 수집하도록 기능을 구현한 것인데
문제가 발생해서 원인을 찾는 중입니다
시스템 버그나 rsyslogd 문제가 아닌것 같습니다
jounalctl로 출력된 결과로 미루어 오류가 한번 나고
정상종료한 것인데 rsyslogd설정에 authpriv 기록을하고
was 서버가 원격로그저장 서버인데 또 전송한 것이 원인입니다
db하고 응용서버에도 자체 기록하도록 설정되어 있는데 미처 확인을 못했습니다
아마 기록되어 있고 단일 문제로로 한줄씩 기록되어 있을거 같습니다
출근하면 바로 테스트할 예정입니다
한쪽 서버만 집중해서 다른쪽 서버 상태를 제대로 테스트 못했네요
와이어샤크로 다른 서버에서 로그가 전송중인지 체크했는데 안하고 있습니다
자체 서버에서는 이루어지고 있다면 확실한 것 같습니다
자체루프백이니 다른 툴 사용해서 체크하면 답이 나올겁니다
다시 한번 감사드립니다

박주연 2019-03

찾으시는게 아래 메시지 때문 아닌가요?
pam_systemd(sshd:session): Failed to release session: Interrupted system call
위 메시지가 생기는 원인은 rsyslogd 와는 관련이 없습니다. (ssh 접속해서 돌리는 프로그램 관련문제로 추정됨)

log 관련 구조나 동작 과정을 잘못 알고 계신듯 합니다.
로그를 일부만 올리셨기에 확정할수 없으나
올리신 내용만으로는 중복 또는 루프가 도는 기록이 없습니다.
어떤걸 보고 전송이 안됐다고 하시는지.......
참고로 로그 전송 테스트는 logger 를 사용하여 점검할수 있습니다.
리모트 전송방법도 설정에 따라 여러가지라 어떤식으로 와이어샤크로 점검하셨다는건지........

online9 2019-03

pam_systemd(sshd:session): Failed to release session: Interrupted system call
위의 오류는 ssh 터미널 프로그램 문제로 발생한 것 입니다.
. . .
Mar  4 16:07:27 dev-app sshd[14381]: pam_systemd(sshd:session): Failed to release session: Interrupted system call
Mar  4 19:05:22 dev-db sshd[3664]: pam_systemd(sshd:session): Failed to release session: Interrupted system call
Mar  4 16:07:15 dev-was sshd[9346]: pam_systemd(sshd:session): Failed to release session: Interrupted system call
. . .
이렇게 표시했는데 제가 잘못 글을 썼습니다.
계속 기록되고 있다고  . . .으로만 표시해서 오해가 있었습니다.
위 글을 수정했습니다.
로그 저장장치는 장비마다 다른데 최소 2t입니다.

rsyslogd설정이 잘못된 것으로 was 서버가 로그 수집 서버로 되어 있는데 관련 설정을
빼고 글을 올렸습니다. /etc/rsyslogd.conf 파일 설정에 다음과 같이 was, db, app 서버가 모두 동일하게 되어 있습니다.
authpriv.error                                              @192.168.0.11
was 서버가 log 수집 서버가 되는데 authpriv.error 를 기록하고 다시 자기 자신에게 전송하게 설정이 되어서
디스크가 다 찰때까지 기록하고 있었습니다.
위 내용과 더 붙여서 was 서버쪽 rsyslogd의 서버 설정에 다음 내용이 추가되어 있어서
. . . 중략
if ($fromhost-ip == '127.0.0.1') then {
*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                :omusrmsg:*
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log
}
authpriv.error                                              @192.168.0.11
. . . 중략
로그에 기록하고 다시 자신에게 재전송해서 생긴 문제입니다.
db 서버와 app 서버에서 패킷이 was쪽으로 지속적으로 나가는 것인지 와이어샤크로 점검한 것입니다.
결국 자신에게 보내는 local loopback 점검이라서 다음 명령으로 확인했습니다.
#tcpdump -i lo
10:45:34.919129 IP dev-was.4694 > mcso6-wwp.syslog: SYSLOG authpriv.error, length: 120
10:45:34.919231 IP dev-was.4694 > mcso6-wwp.syslog: SYSLOG authpriv.error, length: 119
10:45:34.919238 IP dev-was.4694 > mcso6-wwp.syslog: SYSLOG authpriv.error, length: 120
. . .  중략 - 무한반복으로 loopback으로 전송
결국 자신에게 다시 보내는
authpriv.error                                              @192.168.0.11
위 설정문제였습니다.
알려주신 logger 테스트는 구글을 통해검색하고 재현 테스트 했습니다.
다시 한번 감사합니다.