journalctl -u와 -b 차이: 이번 부팅의 서비스 오류만 보는 법

서비스가 지금은 멀쩡하게 보이는데 재부팅 직후에는 실패했다고 한다. 로그를 처음부터 끝까지 읽으면 이전 장애와 이번 장애가 뒤섞인다. 이럴 때는 서비스 이름과 부팅 시점을 나눠 필터링하면 된다. journalctl -u는 서비스 범위를, -b는 부팅 범위를 좁힌다.

journalctl -u는 서비스의 기록을 고른다

도식에서 -u는 특정 서비스의 기록을 고르고, -b는 그중 현재 부팅에 속한 기록만 남긴다. 두 옵션을 함께 쓰면 서비스 범위와 시간 범위의 교집합을 읽게 된다.

demo-web.service는 설명용 유닛 이름이다. 실제 시스템에서는 systemctl status에 표시된 유닛 이름을 확인한 다음 사용한다.

sudo systemctl status demo-web.service
sudo journalctl -u demo-web.service

첫 명령으로 현재 상태와 관련 메시지의 단서를 얻고, 두 번째 명령으로 해당 서비스의 기록을 본다. journalctl을 아무 조건 없이 실행하면 접근 가능한 다른 서비스의 메시지도 섞일 수 있다. 반대로 -u만 사용하면 현재 부팅뿐 아니라 보존된 이전 부팅 기록까지 보일 수 있다. 이전 기록이 남아 있는지는 시스템의 로그 보관 설정에 따라 다르다.

-b를 더하면 이번 부팅으로 범위를 줄인다

재부팅 직후 문제만 보고 싶다면 필터를 함께 사용한다.

sudo journalctl -b -u demo-web.service

-b는 현재 부팅의 로그를 선택하고, -u는 지정 서비스의 로그를 선택한다. 두 조건을 함께 걸면 이번 부팅에서 그 서비스와 관련된 기록으로 범위가 줄어든다. 부팅 필터의 정확한 동작은 systemd의 journalctl 설명으로 확인했다.

이 명령이 빈 결과를 준다면 서비스가 정상이라는 뜻은 아니다. 유닛 이름을 잘못 적었거나, 해당 시점의 기록을 읽을 권한이 없거나, 로그가 보존되지 않았을 수 있다. 이름·권한·부팅 범위를 차례로 확인한다. 화면 한 줄만 보고 결론 내리기보다 실패 시각 전후의 메시지 순서를 함께 읽자.

오류를 찾은 뒤 무엇을 비교할까?

상태 화면에는 ‘failed’가 보이는데 로그에는 실행 파일을 찾지 못했다면 서비스 설정이나 파일 위치를 점검한다. 네트워크 준비 전 연결 실패가 보인다면 시작 순서와 의존 관계를 확인한다. 이 예들은 가능한 점검 방향이지 특정 서버의 실제 장애를 재현한 결과가 아니다.

서비스 시작 실패를 해결하려고 바로 반복 재시작하면 오류 시점이 늘어나 원래 실패를 읽기 어려워질 수 있다. 먼저 로그 범위와 시각을 기록한 뒤, 한 가지 설정을 바꾸고 다시 시도한다. 로그에는 사용자 입력이나 민감한 오류 내용이 포함될 수 있으므로 외부 공유 전 가림 처리도 필요하다.

핵심 요약: 서비스와 부팅 필터를 함께 쓴다

journalctl -u 서비스명은 해당 서비스의 기록을, journalctl -b -u 서비스명은 이번 부팅의 해당 서비스 기록을 본다. 결과가 비어 있을 때는 정상이라고 단정하지 말고 이름·권한·보관 범위를 확인하자.