Systemd가 패닉 모드에 들어간 이유를 정확히 확인하는 방법

Systemd가 패닉 모드에 들어간 이유를 정확히 확인하는 방법

Debian Jessie를 실행하는 내 데스크탑 컴퓨터는 부팅할 때마다 비상 모드 쉘로 들어갑니다. 화면에는 journalctl -xb원인 찾기 및 사용을 사용하여 systemctl default시동을 계속하라는 메시지가 표시됩니다. 을 실행하면 systemctl default몇 주 동안 시스템을 사용한 후에도 눈에 띄는 오류 없이 시스템이 계속 부팅됩니다.

그 과정 전반에 걸쳐 journalctl -xb급박한 고민에 빠질 뚜렷한 이유가 없었습니다. 쉽게 판단할 수 있는 방법이 있나요?정확히비상 모드로 전환하기로 결정한 이유는 무엇입니까? 문제가 어디에 있는지 알 수 있는 다른 플래그나 부팅 옵션이 있습니까?

답변1

오류는 옆에 있는 장치에 대한 설명과 함께 [ FAIL ]콘솔(대신)에 빨간색으로 표시 되어야 합니다. [ OK ]종종 첫 번째 실패가 가장 중요합니다. 위로 스크롤하여 지난 몇 개의 출력 화면을 보려면 콘솔에서 Shift+pageup을 사용하세요. 출력량이 너무 많으면 작동하지 않을 수 있습니다.

이 기능은 일반적으로 [ OK ]메시지가 표시되지 않는 경우 에도 작동합니다(예: 데비안에서 사용하는 커널 명령줄로 인해). quiet첫 번째 실패 시 systemd는 상세 모드로 전환됩니다.

그렇지 않으면 옵션 없이 를 사용할 수 있으며 systemctl결함이 빨간색으로 강조 표시된 알려진 셀의 큰 목록이 표시됩니다. 실패한 항목만 표시하려면 systemctl --state=failed또는 를 사용하십시오 systemctl --failed.


유닛 파일을 검색하는 경우 emergency.target부팅 을 .mount. local-fs.target또는 initramfs가 systemd를 사용하는 경우 initramfs가 루트 파일 시스템을 마운트할 수 없는 경우.

local-fs.target가지다 OnFailure=emergency.target. 로컬 파일 시스템의 단위가 local-fs.target의 Requires 목록에 자동으로 추가되기 때문에 실패합니다(존재하지 않는 한 DefaultDependencies=no).

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

답변2

가끔씩 "유지 관리 모드" 프롬프트가 표시되고 오류를 찾기 위해 로그를 스크롤해야 합니다. Journalctl은 페이지네이터로 less를 사용하므로 검색에 더 적은 단축키를 적용할 수 있어야 합니다.

일반적으로 저는 검색 기능(/)을 사용하여 "오류", "경고" 또는 "실패"에 해당하는 항목을 검색합니다. 그리고 -i가 대소문자를 구분하지 않는 검색을 강제하는지 확인하세요.

그래서 내 키 입력은 다음과 같은 경향이 있습니다.

-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)

기술적으로 이것은 정확한 문제에 대한 철저하거나 정확한 검색은 아니지만 이런 식으로 시작 문제를 놓친 적이 없습니다.

관련성이 덜한 키보드 단축키는 다음과 같습니다.

http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for- Effective-navigation/

답변3

때때로 journalctl -xb"less"를 호출기로 사용하면 문제가 빨리 발견되는 것을 방지할 수 있습니다. 대신에 다음을 사용합니다.

journalctl -xb | egrep -i '(error|fail|warn)'

조용하지 않은 시작 시퀀스의 복사본 도 있으며 /var/log/boot.log색상 구분 문제를 쉽게 확인할 수 있습니다.

more /var/log/boot.log

"less" 대신 "more"를 사용하는 이유는 후자의 기본 동작이 제어 시퀀스를 벗어나는 것이므로 색상 코딩을 (에헴) 쓸데없는 진창으로 변경하기 때문입니다.

관련 정보