커널 업그레이드 외에도 재부팅이 필요한 Linux 시스템에 변경 사항이 있습니까? 재부팅으로 작업이 더 쉬워지는 상황이 있지만 재부팅을 제외하고는 달성 할 수없는 상황이 있습니까?
명확히하기 위해 : 나는 하드웨어 오작동으로 고통받지 않는 전형적인 데스크탑 또는 서버 시스템을 생각하고 있습니다.
커널 업그레이드 외에도 재부팅이 필요한 Linux 시스템에 변경 사항이 있습니까? 재부팅으로 작업이 더 쉬워지는 상황이 있지만 재부팅을 제외하고는 달성 할 수없는 상황이 있습니까?
명확히하기 위해 : 나는 하드웨어 오작동으로 고통받지 않는 전형적인 데스크탑 또는 서버 시스템을 생각하고 있습니다.
답변:
몇 가지 사항이 떠 오릅니다.
커널 패닉 에서 복구
정의에 따르면 커널 패닉은 커널을 다시 시작하지 않고는 복구 할 수 없습니다.
터미널 액세스없이 떠나는 중단에서 복구
시스템이 응답하지 않고 복구 명령을 실행할 수있는 방법을 찾지 못한 경우 재부팅 만하면됩니다. 일반적으로 수동 전원 순환을 피하고 싶을 것입니다. 이러한 상황에서 Linux 커널에는 Magic SysRq 지원 기능이있어 비상시 시스템을 재부팅하는 데 사용할 수 있습니다.
긴만큼 CONFIG_MAGIC_SYSRQ
옵션 커널 설정에서 활성화 된, 그리고 kernel.sysrq
sysctl
옵션이 활성화되어, 당신은 마법 SysRq를 키 조합으로 커널에 직접 명령을 실행할 수 있습니다 :
유의 Alt+ SysRq수단은 아래 누르고 누른 Alt 후, 길게 누름 SysRq (통상 PrintScrn키).
SIGTERM
를 제외한 모든 프로세스로 전송 하여 init
정상적으로 종료 할 수있는 기회 제공SIGKILL
을 제외한 모든 프로세스로 보내 init
강제로 종료Alt+ SysRq+ b: 재부팅 또는
Alt+ SysRq+ o: 셧다운
매직 SysRq 키 조합이 정상적인 재부팅을 시도하기위한 니모닉은 다음과 같습니다.
" R EBOOT E VEN I F S 템 U tterly B의 roke "
헤드리스 서버의 경우 네트워크를 통해 원격 SysRq 시퀀스를 가능하게 하는 iptables 대상 도 있습니다.
부팅 할 수없는 상태에서 복구
시스템이 이미 정기적으로 부팅 할 수없는 상태가 된 경우 (예 : 시스템 업그레이드 실패, 파일 시스템 손상 등) 시스템에서 복구 콘솔에 액세스하는 유일한 방법은 재부팅하는 것입니다 적절한 부팅 시간 옵션 사용
부팅시 커널 매개 변수 변경
일부 커널 매개 변수 (예 : audit
커널 감사 활성화 / 비활성화)는 커널이 부팅시로드 될 때만 설정할 수 있습니다.
재부팅하려는 위치를 두 번 생각할 수 있습니다.
시스템이 올바른 상태로 부팅 될 수 있는지 확인해야 할 때.
한 번은 데몬이 실행되는 동안 구성된 데몬이있는 시스템에서 일했습니다. 몇 년 동안 실행 된 후 전원 장애로 인해 재부팅이되었지만 데몬은 시작 프로세스의 일부가 아니 었으며 몇 년 전에 어떻게 구성했는지 알 수 없었습니다. 시스템을 재구성하는 방법을 알아내는 동안 시스템이 며칠 동안 중단되었습니다.
실제로 재부팅하는 것은 정전 후 시스템이 올바르게 다시 시작되는지 확인하는 유일한 방법입니다.
시스템 라이브러리가 업데이트 된 경우
시스템의 많은 앱 / 서버와 공유되는 라이브러리에서 주요 보안 결함이 발견되었다고 가정 해 봅시다. 재부팅하지 않고 라이브러리를 업데이트 할 수 있지만 안전하지 않은 라이브러리가로드 된 상태로 몇 개의 프로세스가 계속 실행되고 있습니까? 구식 라이브러리를 사용하여 모든 것을 힘들게 다시 시작할 수 있지만 (알 수있는 경우) 오류가 발생하기 쉬우 며 재부팅하는 것보다 시간이 오래 걸릴 수 있습니다.
재부팅은 실행중인 모든 프로세스가 여전히 오래된 버그가있는 라이브러리를 사용하지 않도록하는 가장 좋은 방법입니다.
lsof
를 업그레이드하기 전에 사용하여 라이브러리가 메모리 공간에 매핑 된 프로세스를 확인할 수 있습니다.