CentOS 7에서 rsyslog 서비스가 로그를 기록하지 않을 때 해결하는 방법

적용 환경

1. 가장 먼저 확인할 항목

로그가 기록되지 않는다고 판단하기 전에 현재 서버 시간, rsyslog 패키지 설치 여부, 서비스 상태, 최근 로그 파일의 수정 시각을 먼저 확인합니다.

date
rpm -q rsyslog
systemctl is-active rsyslog.service
systemctl is-enabled rsyslog.service
ls -lh --time-style=long-iso /var/log/messages /var/log/secure /var/log/cron 2>/dev/null

rpm -q rsyslog에서 패키지 정보가 표시되고, systemctl is-active 결과가 active이면 데몬 자체는 실행 중입니다. 그러나 서비스가 실행 중이라는 사실만으로 실제 파일 기록까지 정상이라는 의미는 아니므로 다음 단계에서 테스트 메시지를 직접 발생시켜 확인해야 합니다.

2. rsyslog 서비스 상태와 오류 확인

서비스가 중지되어 있거나 시작 직후 실패하는 경우에는 먼저 systemd 상태와 현재 부팅에서의 rsyslog 로그를 확인합니다.

sudo systemctl status rsyslog.service --no-pager -l
sudo journalctl -u rsyslog.service -b --no-pager

출력에서 설정 문법 오류, 파일 열기 실패, Permission denied, No space left on device, Too many open files, imjournal 상태 파일 오류, 출력 action의 suspended 메시지가 있는지 확인합니다.

서비스가 단순히 비활성화되어 있다면 다음 명령으로 시작하고 부팅 시 자동 시작을 활성화할 수 있습니다.

sudo systemctl enable --now rsyslog.service
sudo systemctl is-active rsyslog.service
sudo systemctl is-enabled rsyslog.service

시작에 실패한다면 반복해서 재시작하기보다 journalctl의 첫 번째 오류와 다음 단계의 설정 문법 검사 결과를 먼저 확인하십시오.

3. logger로 실제 기록 경로 확인

logger 명령은 로컬 syslog 경로로 테스트 메시지를 전송하는 데 사용할 수 있습니다. 테스트 메시지를 발생시킨 뒤 systemd journal과 /var/log/messages 양쪽에서 검색하면 장애 지점을 빠르게 구분할 수 있습니다.

logger -t rsyslog-test "VISION IDC rsyslog test message"

sudo journalctl -t rsyslog-test --since "5 minutes ago" --no-pager
sudo grep -F "VISION IDC rsyslog test message" /var/log/messages

4. rsyslog 설정 문법과 출력 규칙 확인

설정 문법 검사

rsyslog는 기본 설정 파일과 /etc/rsyslog.d/에 포함된 설정을 함께 읽습니다. 설정을 수정하기 전에 먼저 구문 검사를 실행합니다.

sudo rsyslogd -N1

오류가 없으면 검증 완료 메시지가 표시됩니다. 파일명이나 줄 번호와 함께 오류가 출력되면 해당 설정을 수정한 뒤 같은 명령을 반복해 오류가 없어졌는지 확인하십시오.

설정 파일과 include 확인

sudo grep -nEv '^[[:space:]]*($|#)' /etc/rsyslog.conf
sudo find /etc/rsyslog.d -maxdepth 1 -type f -name '*.conf' -print

특히 최근 추가한 필터, stop 또는 ~ 폐기 규칙, 잘못된 파일 경로, 잘못된 facility·severity 선택 조건이 앞쪽 규칙에서 메시지를 차단하고 있지 않은지 확인합니다.

/var/log/messages, /var/log/secure, /var/log/cron 등 주요 출력 파일을 지정하는 규칙이 남아 있는지 다음과 같이 검색할 수 있습니다.

sudo grep -R --line-number -E '/var/log/(messages|secure|cron|maillog|spooler)' \
  /etc/rsyslog.conf /etc/rsyslog.d 2>/dev/null

5. systemd journal과 rsyslog 입력 확인

RHEL 7 계열에서는 systemd journal과 rsyslog가 함께 동작하며, rsyslog는 imjournal 또는 Unix socket 입력을 통해 메시지를 받을 수 있습니다. journal에는 메시지가 있는데 rsyslog 파일에는 기록되지 않는다면 입력 모듈과 관련 상태를 확인합니다.

sudo systemctl status systemd-journald.service --no-pager -l
sudo journalctl -u systemd-journald.service -b --no-pager
sudo grep -R --line-number -E 'imjournal|imuxsock|IMJournal|SysSock' \
  /etc/rsyslog.conf /etc/rsyslog.d 2>/dev/null

rsyslog 서비스 로그에 imjournal 관련 오류가 있다면 해당 메시지를 우선 기준으로 진단합니다. Red Hat은 RHEL 7 환경에서 /var/lib/rsyslog/imjournal.state 상태 파일 관련 오류가 발생해 로그 수신에 문제가 생길 수 있는 사례를 문서화하고 있습니다.

6. 디스크·권한·SELinux 문제 확인

디스크 블록과 inode 확인

로그 디렉터리가 있는 파일시스템의 블록이나 inode가 소진되면 rsyslog가 정상 실행 중이어도 새로운 로그 파일 데이터를 기록할 수 없습니다.

df -hT /var /var/log
df -i /var /var/log

Use%가 100%에 가깝거나 inode의 IUse%가 100%라면 rsyslog 설정 자체보다 저장 공간 문제를 먼저 해결해야 합니다.

파일 디스크립터 오류 확인

Red Hat은 RHEL 7에서 rsyslog가 Too many open files 오류로 /var/log/messages, /var/log/secure 등의 기록을 중단할 수 있는 사례를 문서화하고 있습니다. 최근 서비스 로그에서 관련 문구를 확인합니다.

sudo journalctl -u rsyslog.service -b --no-pager | \
  grep -iE 'too many open files|file descriptor|suspended|fopen'

파일 권한과 SELinux 차단 확인

기본 로그 파일이 아니라 사용자 정의 경로에 기록하도록 설정했다면 디렉터리 권한과 SELinux 정책 때문에 쓰기가 차단될 수 있습니다. 먼저 실제 출력 경로의 권한과 최근 AVC 거부 기록을 확인합니다.

sudo ls -ldZ /var/log
sudo ls -lZ /var/log/messages 2>/dev/null
sudo ausearch -m AVC -ts recent 2>/dev/null | grep -i rsyslog

SELinux 거부 기록이 확인된다면 SELinux를 비활성화하기보다 출력 경로와 필요한 보안 컨텍스트를 먼저 검토해야 합니다. 단순히 chmod 777로 권한을 풀어 로그 기록을 복구하는 방법은 권장하지 않습니다.

7. 설정 수정 후 안전하게 복구

설정 파일을 수정해야 한다면 먼저 현재 설정을 백업합니다. /etc/rsyslog.d/ 안에 백업 파일을 두면 확장자나 include 조건에 따라 다시 읽힐 수 있으므로 백업은 해당 디렉터리 밖에 보관합니다.

sudo cp -a /etc/rsyslog.conf /root/rsyslog.conf.backup
sudo cp -a /etc/rsyslog.d /root/rsyslog.d.backup

수정 후에는 반드시 문법 검사를 먼저 통과시킨 다음 서비스를 재시작합니다.

sudo rsyslogd -N1
sudo systemctl restart rsyslog.service
sudo systemctl status rsyslog.service --no-pager -l

서비스가 다시 active (running) 상태가 되고 새로운 오류가 없다면 logger 테스트를 다시 실행하여 파일 기록까지 확인합니다.

8. 자주 발생하는 오류와 해결 방법

9. 복구 여부 확인

조치가 끝난 뒤에는 서비스 상태만 확인하지 말고 실제 메시지가 journal과 파일에 모두 기록되는지 다시 검증합니다.

sudo rsyslogd -N1
sudo systemctl is-active rsyslog.service

logger -t rsyslog-test "VISION IDC rsyslog recovery test"

sudo journalctl -t rsyslog-test --since "5 minutes ago" --no-pager
sudo grep -F "VISION IDC rsyslog recovery test" /var/log/messages

문법 검사가 오류 없이 끝나고, rsyslog 서비스가 active이며, 테스트 메시지가 /var/log/messages에 기록되면 기본 로컬 파일 로깅 경로가 복구된 것으로 볼 수 있습니다.

특정 애플리케이션의 로그만 계속 누락된다면 해당 애플리케이션의 facility·severity, 별도 /etc/rsyslog.d/*.conf 규칙, 전용 로그 파일 권한을 추가로 확인하십시오.

관련 VISION IDC 기술자료

• CentOS 7에서 No space left on device 오류가 발생할 때 원인을 확인하는 방법
• CentOS 7에서 파일 디스크립터 제한을 확인하고 변경하는 방법
• CentOS 7에서 yum 저장소 오류를 Vault 저장소로 변경하여 해결하는 방법

공식 참고자료

• Red Hat — RHEL 7 System Administrator’s Guide, Viewing and Managing Log Files: rsyslog와 systemd journal의 연동, imjournal 및 로그 관리 구조를 확인했습니다. 공식 문서. 조회일: 2026년 9월 14일.
• Red Hat — Debugging Rsyslog: 설정 검증에 rsyslogd -N 1을 사용하는 방법을 확인했습니다. 공식 문서. 조회일: 2026년 9월 14일.
• rsyslog Project — Basic Configuration / Installation: 기본 설정 경로, systemctl status rsyslog, rsyslogd -N1, logger를 이용한 검증 방법을 확인했습니다. 공식 문서. 조회일: 2026년 9월 14일.
• rsyslog Project — imjournal: systemd journal에서 메시지를 가져오는 imjournal 모듈의 역할과 상태 파일 동작을 확인했습니다. 공식 문서. 조회일: 2026년 9월 14일.
• CentOS Project — CentOS Linux: CentOS Linux 7의 지원 종료일이 2024년 6월 30일임을 확인했습니다. 공식 안내. 조회일: 2026년 9월 14일.

자주 묻는 질문

rsyslog 서비스가 active인데도 로그가 기록되지 않을 수 있나요?

가능합니다. 서비스 프로세스는 실행 중이어도 입력 모듈, 필터 규칙, 파일 출력 action, 디스크 공간, 파일 디스크립터, 권한 문제 때문에 실제 파일 기록이 실패할 수 있습니다. logger 테스트와 journalctl -u rsyslog을 함께 확인하는 것이 좋습니다.

journalctl에는 로그가 있는데 /var/log/messages에는 왜 없나요?

systemd-journald까지는 메시지가 정상적으로 도달했지만 rsyslog가 journal에서 메시지를 읽지 못하거나, rsyslog 필터 또는 파일 출력 단계에서 누락되었을 가능성이 있습니다. imjournal/imuxsock 설정과 출력 규칙을 확인하십시오.

rsyslog.conf를 수정한 뒤 바로 restart해도 되나요?

먼저 rsyslogd -N1로 설정 문법을 검사하는 것이 안전합니다. 문법 오류가 있는 상태로 서비스를 재시작하면 기존에 동작하던 로깅까지 중단될 수 있습니다.

SELinux를 끄면 로그 기록 문제를 해결할 수 있나요?

SELinux 거부가 원인이라면 일시적으로 증상이 달라질 수 있지만, 보안 기능 전체를 비활성화하는 방식은 권장하지 않습니다. ausearch로 실제 AVC 거부를 확인하고 사용자 정의 로그 경로의 보안 컨텍스트와 정책을 올바르게 수정하는 것이 우선입니다.