Skip to main content

저널로그에서 Data hash table of /run/log/journal/... 의 반복적인 출력 이슈

이 글을 쓴이유

서버 점검중에 로그데이터중 반복적으로 출력시키는 것을 확인했죠

$> dmesg -T 
[일  12월 10 18:20:06 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19207 of 25607 items, 8388608 file size, 436 bytes per hash table item), suggesting rotation.
[일  12월 10 18:20:06 2024] systemd-journald[655]: /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal: Journal header limits reached or header out-of-date, rotating.
[일  12월 10 19:30:37 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19206 of 25607 items, 14749696 file size, 767 bytes per hash table item), suggesting rotation.
[일  12월 10 19:30:37 2024] systemd-journald[655]: /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal: Journal header limits reached or header out-of-date, rotating.
[일  12월 11 19:40:48 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19206 of 25607 items, 8388608 file size, 436 bytes per hash table item), suggesting rotation.

처음에 화들짝. 😳 (디스크 깨졌나...)

자세히 보니 info레벨의 로그였고 저널(journald)데몬에 의해 기록된 내용이였어요.

내용자체는 로테이트 했다는 info성 메시지였죠

 

Journald?

  1. systemd서비스의 로그데이터를 저널(Journal)이라는 형태로 저장을 하게 되는데, OS 부팅이후 발생하는 서비스 및 OS로그들을 확인할 수 있는 기능입니다. (약간... rsyslog와 좀 비슷한 역활을 하고 있는녀석이겠네요)
  2. 바이너리 형태로 저장되다 보니 vi로는 확인이 안되고 journalctl 이라는 별도의 바이너리를 통해 데이터 확인을 할 수 있어요
  3. dmesg에 나왔던 이유는 journald.conf 파일에 ForwardToWall값이 yes(디폴트)로 되어 있어서 출력된 이벤트예요.

 

해결방법

  1. journald.conf 파일에서 ForwardToWall값을 no로 바꾼 후 데몬 재기동 해주면 됩니다.
    $>vi /etc/systemd/journald.conf
...
ForwardToWall=no
...
  2. 하나만 더 찾아봤어요. 왜냐하면 관리하고 있는서버가 상당히 많은데 일부 서버에서만 저런 유사한 로그데이터를 출력하고 있었거든요.(로그 용량이 차서 로테이트 돌은건 OK, 그래도 너무 빈번한게 왜 그럴까..였죠)
    1. 서버 상태 점검 : 이상무
    2. 하드웨어 상태 점검 : 이상무
    3. 디스크 사용량(+inode값 포함) : 어? 저널로그경로의 데이터가 너무 크네요.
      $> du -hs /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4
50G   .

      시스템 로그를 50G나 먹고 있었다니.. (배부르냐?!)

    4. uptime을 확인해보니 이제 겨우 40일 지났습니다...
    5. journald는 시스템 로그를 기록하는 데몬이라고 했죠.? 관련된 시스템 로그를 보다 보니.... 아니나 다를까.
      cron에 관련된 용량이 엄청 났던거죠.
      $>journalctl --file=xxxxxx
...
crond
crond
crond
crond
crond
...

    6. 네.. 그렇습니다. Crontab에 시간단위로 실행하는 스크립트가 있는데 표준 출력+에러 까지 모두 기록하다보니 저렇게 어마어마한 용량을 자랑하고 있었네요.
    7. 해당 스크립트의 표준출력은 뺐습니다. (어짜피 들여다보고 분석할 필요가 없었거든요)

 

반영하기

  1. systemd-journald 데몬을 재실행해주면 됩니다.
    1. 자.. 지금 구동상태를 한번 볼까요?
      $> systemctl status systemd-journald
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Sat 2023-01-09 22:54:40 KST; 6 days ago
TriggeredBy: ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 655 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 35765)
     Memory: 91.2M
        CPU: 36.469s
     CGroup: /system.slice/systemd-journald.service
             └─655 /usr/lib/systemd/systemd-journald
[일  12월 10 18:20:06 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19207 of 25607 items, 8388608 file size, 436 bytes per hash table item), suggesting rotation.
[일  12월 10 18:20:06 2024] systemd-journald[655]: /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal: Journal header limits reached or header out-of-date, rotating.
[일  12월 10 19:30:37 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19206 of 25607 items, 14749696 file size, 767 bytes per hash table item), suggesting rotation.
[일  12월 10 19:30:37 2024] systemd-journald[655]: /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal: Journal header limits reached or header out-of-date, rotating.
[일  12월 11 19:40:48 2024] systemd-journald[655]: Data hash table of /run/log/journal/8d8bce04dde6433198c5ff39a2265dd4/system.journal has a fill level at 75.0 (19206 of 25607 items, 8388608 file size, 436 bytes per hash table item), suggesting rotation.

      * 아까 dmesg에서 봤던 로그데이터가 여기서 보이네요.

    2. 서비스 재기동 파파팟!
      $> systemctl restart systemd-journald

    3. 재기동 후 잘 뜨고 있는지 확인
      $> systemctl status systemd-journald
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2024-01-15 23:07:33 KST; 1s ago
TriggeredBy: ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 127119 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 35765)
     Memory: 1.4M
        CPU: 14ms
     CGroup: /system.slice/systemd-journald.service
             └─127119 /usr/lib/systemd/systemd-journald

 1월 15 23:07:33 systemd-journald[127119]: Journal started
 1월 15 23:07:33 systemd-journald[127119]: Runtime Journal (/run/log/journal/8d8bce04dde6433198c5ff39a2265dd4) is 108.9M, max 112.5M, 3.5M free.

결론

제 경우는 그랬습니다.  한시간 단위로 실행하는 스크립트 배포 후 cron에 관련된 시스템 로그용량 증가 -> 증가속도가 빈번하게 journald 에서 잦은 로그 순환  (결국 info성 로그.?? )

 

Reference

No Comments
Back to top
Entity Select