systemd journald의 Storage=auto는 /var/log/journal 디렉터리가 있으면 persistent처럼 동작하고, 없으면 volatile 저장을 선택할 수 있습니다. 휘발 저장은 /run/log/journal 경로를 사용하며 재부팅 뒤 내용이 사라질 수 있습니다.
journalctl에서 현재 부팅 기록이 보인다는 사실은 이전 부팅 기록의 보존을 증명하지 않습니다. 설정값, 실제 저장 위치, 이전 boot 조회, 디스크·보존 상태를 별도로 확인해야 합니다. 아래는 Oracle Linux 10 문서 범위의 학습 사례이며 실제 설정을 바꾸지 않습니다.
현재 로그가 보이는 것과 이전 부팅 기록은 별개입니다
journalctl은 호출한 사용자에게 접근 가능한 journal 항목을 조회합니다. 명령 결과에 최근 로그가 보인다고 해서 재부팅 전 기록도 영구 보존된 것은 아닙니다. --boot로 이전 부팅을 요청해도 저장 방식이 휘발성이고 재부팅 과정에서 내용이 사라졌다면 조회할 자료가 남아 있지 않을 수 있습니다. 먼저 질문을 ‘현재 부팅 로그가 있나’와 ‘이전 부팅 로그가 보존됐나’로 나누세요.
Storage=auto는 저장 디렉터리의 존재 조건을 봅니다
| 설정 | 기본 동작 | 확인할 경로 |
|---|---|---|
| volatile | 메모리 기반 휘발 저장 | /run/log/journal |
| persistent | 가능하면 디스크에 영구 저장 | /var/log/journal |
| auto | /var/log/journal 존재 시 영구, 없으면 휘발 | /var/log/journal 존재 여부 |
| none | journal 저장을 하지 않음 | 다른 전달 대상은 별도 확인 |
Oracle Linux 10 systemd 안내는 Storage=auto일 때 /var/log/journal 디렉터리가 있으면 persistent로 바뀌고, 없으면 기본적으로 휘발 저장이라고 설명합니다. 그래서 설정 파일에서 Storage=auto 문자열만 읽고 ‘재부팅 후 로그가 남는다’고 결론 내리면 안 됩니다. 실제 저장 디렉터리와 저장 위치를 함께 확인해야 합니다. Storage=persistent여도 파일시스템이 쓰기 불가하거나 저장 공간이 부족하면 기대한 기록을 보장할 수 없습니다.
가상 장애 기록을 세 가지 증거로 판정합니다
| 관찰 | 가상값 | 말할 수 있는 범위 |
|---|---|---|
| Storage 설정 | auto | 디렉터리 존재 조건이 중요함 |
| 영구 경로 | /var/log/journal 없음 | auto 분기에서 volatile일 가능성 |
| journalctl -b -1 | 항목 없음 | 저장 부재·권한·필터 등 추가 원인 확인 필요 |
이 예시에서 과거 로그가 화면에 없다는 사실만으로 특정 설정이 원인이라고 단정하지 않습니다. /var/log/journal이 실제로 없었는지, 해당 namespace를 조회했는지, 사용자가 이전 부팅 journal을 읽을 권한이 있는지, 로그가 보존 기간이나 공간 제한으로 정리됐는지 확인해야 합니다. journalctl --list-boots도 현재 보유한 journal 인덱스를 보여 줄 뿐, 그 기록이 원래부터 생성됐다는 증거는 아닙니다.
--flush는 이미 없어진 기록을 복원하지 않습니다
journalctl --flush는 저장이 활성화된 조건에서 /run/log/journal에 있던 기록을 /var/log/journal로 이동시키도록 journald에 요청합니다. 이 동작은 현재 부팅 중 기록 전환을 다루며, 재부팅 때 이미 사라진 과거 데이터를 되살리는 복구 명령이 아닙니다. Oracle 문서에는 설정 디렉터리를 만들거나 서비스를 재시작하는 절차도 나오지만, 이 설명에서는 운영 중 어떤 변경 명령도 수행하라고 권하지 않습니다. 변경은 승인과 보존 정책 확인 후 담당자가 진행해야 합니다.
- 해당 서버의 systemd 버전과 journal namespace를 기록합니다.
- 설정 파일과 drop-in 우선순위를 확인하되 현재 적용값과 파일 문구를 구별합니다.
/var/log/journal과/run/log/journal의 존재·권한·실제 사용 경로를 읽습니다.- 현재 boot와 이전 boot를 같은 시간·필터 조건으로 조회합니다.
- 저장 공간, 보존·vacuum 정책, 전달 대상과 접근 권한을 따로 점검합니다.
auto를 ‘항상 디스크 저장’으로 번역하지 않습니다
대표 오답은 auto를 automatic backup처럼 이해해 모든 기록이 자동으로 보존된다고 말하는 것입니다. auto는 저장 경로 존재 여부에 따라 동작을 고르는 설정입니다. 또한 rsyslog 등 다른 로그 전달 대상이 있다면 journal 자체 저장과 그쪽 파일 아카이브를 따로 확인해야 합니다. 한쪽 로그가 남아 있다고 다른 보존 경로도 정상이라고 추론하지 마세요.
설정값·경로·조회 결과를 가리고 회상합니다
시험형 문제에서는 먼저 Storage 값을 적고 다음 줄에 /var/log/journal 존재 여부, 마지막 줄에 조회한 boot 범위를 기록합니다. 가상 사례의 Storage=auto와 경로 부재는 volatile 선택을 설명하지만, 기록 부재의 단독 증명은 아닙니다. 부족한 증거가 있으면 ‘영구 저장이 설정되지 않았을 가능성이 있으며 실제 적용값과 로그 보존 경로를 확인해야 한다’고 한정해 답하세요.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
Oracle Linux 10 기본 journal namespace에서 Storage=auto이고 /var/log/journal 디렉터리가 없다고 가정합니다. 재부팅 뒤 이전 boot 로그가 안 보일 때 첫 설명은 무엇이며, 무엇을 더 확인해야 하나요?
정답과 해설 확인
auto 분기에서 휘발 저장일 수 있어 재부팅 뒤 기록이 남지 않았을 가능성이 있습니다. 실제 저장 경로·namespace·접근 권한·보존 상태를 더 확인해야 합니다.Oracle Linux 10 systemd 문서는 auto가 /var/log/journal 존재 여부에 따라 persistent 또는 volatile로 동작한다고 설명합니다. 관찰된 로그 부재는 원인 확정이 아니므로 저장·조회 범위를 추가 점검해야 합니다.