언제 재부팅해야합니까?


27

커널 업그레이드 외에도 재부팅이 필요한 Linux 시스템에 변경 사항이 있습니까? 재부팅으로 작업이 더 쉬워지는 상황이 있지만 재부팅을 제외하고는 달성 할 수없는 상황이 있습니까?

명확히하기 위해 : 나는 하드웨어 오작동으로 고통받지 않는 전형적인 데스크탑 또는 서버 시스템을 생각하고 있습니다.


3
재부팅하지 않고도 모든 작업을 수행 할 수 있습니다. 커널 변경은 ksplice를 사용하여 수행 할 수 있으므로 커널을 핫 스왑 할 수 있습니다. 당신이 고려해야 할 유일한 것은 재부팅하지 않고 모든 것을 만드는 것은 매우 복잡 할 수 있다는 것입니다
Kiwy

4
"리눅스 시스템"은 많은 다른 것을 의미 할 수 있기 때문에 귀하의 질문은 매우 광범위합니다.
Zrin

또한 "변경 사항"은 매우 다양한 상황을 의미 할 수 있습니다. MD 미러의 일부인 고장난 하드 드라이브로부터의 복구가 그러한 변화입니까? 그렇다면 불행하게도 예를 들어 일부 HDD 오류 (일부 HDD 컨트롤러에서)로 인해 시스템이 응답하지 않을 수 있기 때문에 재부팅이 필요할 수 있습니다. 그러나 당신은 아마 그러한 "변화"에 대해 묻지 않을 것입니다 ...
Zrin

3
@Kiwy 기술적으로 ksplice는 커널을 변경 하지 않습니다 . Ksplice를 사용하면 실행중인 커널을 실행하는 동안 패치 할 수 있습니다. kexec를 생각하고있을 수 있는데, 이는 새로운 커널 이미지가 메모리에서 실행중인 커널에 "로드"될 수 있도록합니다.
Thomas Nyman

이것은 Windows XP (나는 결코 지나치지 않았다)는 Windows 설치 이후 4 년 동안 열리지 않은 IE8 (또는 다른 번호)을 방금 업데이트하더라도 다시 시작하지 않는다는 것을 상기시킵니다. 브라우저.
Shahbaz

답변:


44

몇 가지 사항이 떠 오릅니다.

  • 커널 패닉 에서 복구

    정의에 따르면 커널 패닉은 커널을 다시 시작하지 않고는 복구 할 수 없습니다.

  • 터미널 액세스없이 떠나는 중단에서 복구

    시스템이 응답하지 않고 복구 명령을 실행할 수있는 방법을 찾지 못한 경우 재부팅 만하면됩니다. 일반적으로 수동 전원 순환을 피하고 싶을 것입니다. 이러한 상황에서 Linux 커널에는 Magic SysRq 지원 기능이있어 비상시 시스템을 재부팅하는 데 사용할 수 있습니다.

    긴만큼 CONFIG_MAGIC_SYSRQ옵션 커널 설정에서 활성화 된, 그리고 kernel.sysrq sysctl옵션이 활성화되어, 당신은 마법 SysRq를 키 조합으로 커널에 직접 명령을 실행할 수 있습니다 :

    유의 Alt+ SysRq수단은 아래 누르고 누른 Alt 후, 길게 누름 SysRq (통상 PrintScrn키).

    1. Alt+ SysRq+ r: 키보드 제어권 회복
    2. Alt+ SysRq+ e: SIGTERM를 제외한 모든 프로세스로 전송 하여 init정상적으로 종료 할 수있는 기회 제공
    3. Alt+ SysRq+ i: SIGKILL을 제외한 모든 프로세스로 보내 init강제로 종료
    4. Alt+ SysRq+ s: 마운트 된 모든 파일 시스템 동기화 시도
    5. Alt+ SysRq+ u: 모든 파일 시스템을 읽기 전용으로 다시 마운트
    6. Alt+ SysRq+ b: 재부팅 또는

      Alt+ SysRq+ o: 셧다운

    매직 SysRq 키 조합이 정상적인 재부팅을 시도하기위한 니모닉은 다음과 같습니다.

    " R EBOOT E VEN I F S U tterly B의 roke "

    헤드리스 서버의 경우 네트워크를 통해 원격 SysRq 시퀀스를 가능하게 하는 iptables 대상 도 있습니다.

  • 부팅 할 수없는 상태에서 복구

    시스템이 이미 정기적으로 부팅 할 수없는 상태가 된 경우 (예 : 시스템 업그레이드 실패, 파일 시스템 손상 등) 시스템에서 복구 콘솔에 액세스하는 유일한 방법은 재부팅하는 것입니다 적절한 부팅 시간 옵션 사용

  • 부팅시 커널 매개 변수 변경

    일부 커널 매개 변수 (예 : audit커널 감사 활성화 / 비활성화)는 커널이 부팅시로드 될 때만 설정할 수 있습니다.


3
"시스템이 완전히 고장난 경우에도 재부팅"이 경우를 대비하여이 질문을 선호하지만, 그 사실을 잊을 수 없다고 생각합니다.
embedded.kyle

1
kexec를 사용하여 패닉 상태에서 벗어날 수 있으며 완전한 재부팅을 피할 수 있습니다. 이것은 부팅 할 수없는 상태 지점을 벗어나는 경우에도 동일하게 적용됩니다. (적어도 x86 시스템에서는 동일하지 않습니다). 그러나이 답변의 나머지 부분에는 +1입니다.
Vality

@Vality 귀하의 의견에 감사드립니다. kexec가 재부트를 수반하는 경우 아마도 어느 정도의 관점에 달려 있습니다. kdump에 문서 예를 들어 시스템 커널의 메모리 이미지를 보존 재부팅으로 kexec 또는 온 공황을 설명합니다. 부팅 할 수없는 상태에 대한 요점은 kloadc가 도움이되지 않는 bootloader 구성 오류 (예 : 처음 커널로드 실패)와 같은 것을 고려했습니다. 질문의 본질을 감안할 때, 의미론에 관한 의견의 차이는 피할 수 없다고 생각합니다.
Thomas Nyman

@ThomasNyman 자세한 답변을 보내 주셔서 감사합니다. 귀하가 느끼는 정답을 찾으십시오. kexec에 대해 이야기하면 대상 고객이 나이 질문에 불필요하게 복잡하게 될 것입니다. 또한 부트 로더 오류와 관련하여 좋은 지적을합니다.
Vality

인쇄 화면에서 작성된 작은 SysRq는 눈치 채지 못했습니다! 대단해. 커널 모듈 프로그래밍을 배울 때 이것을 알고 있었으면 좋겠습니다!
Shahbaz

2

재부팅하려는 위치를 두 번 생각할 수 있습니다.

  1. 시스템이 올바른 상태로 부팅 될 수 있는지 확인해야 할 때.

    한 번은 데몬이 실행되는 동안 구성된 데몬이있는 시스템에서 일했습니다. 몇 년 동안 실행 된 후 전원 장애로 인해 재부팅이되었지만 데몬은 시작 프로세스의 일부가 아니 었으며 몇 년 전에 어떻게 구성했는지 알 수 없었습니다. 시스템을 재구성하는 방법을 알아내는 동안 시스템이 며칠 동안 중단되었습니다.

    실제로 재부팅하는 것은 정전 후 시스템이 올바르게 다시 시작되는지 확인하는 유일한 방법입니다.

  2. 시스템 라이브러리가 업데이트 된 경우

    시스템의 많은 앱 / 서버와 공유되는 라이브러리에서 주요 보안 결함이 발견되었다고 가정 해 봅시다. 재부팅하지 않고 라이브러리를 업데이트 할 수 있지만 안전하지 않은 라이브러리가로드 된 상태로 몇 개의 프로세스가 계속 실행되고 있습니까? 구식 라이브러리를 사용하여 모든 것을 힘들게 다시 시작할 수 있지만 (알 수있는 경우) 오류가 발생하기 쉬우 며 재부팅하는 것보다 시간이 오래 걸릴 수 있습니다.

    재부팅은 실행중인 모든 프로세스가 여전히 오래된 버그가있는 라이브러리를 사용하지 않도록하는 가장 좋은 방법입니다.


좋은 패키지 관리자를 사용하는 경우 특정 라이브러리에 따라 모든 바이너리를 찾는 더 좋은 방법이 있습니다. 젠투의 revdep-rebuilt가 떠 오릅니다.
Spidey

1
@Spidey :이 바이너리를 다시 빌드 한 후 버그가있는 라이브러리로 실행중인 오래된 프로세스가 없는지 어떻게 확인합니까?
Gabe

1
문제가있는 라이브러리가로드 된 데몬을 어떻게 알 수 있습니까?
Gabe

1
@Gabe 예를 들어 라이브러리 lsof를 업그레이드하기 전에 사용하여 라이브러리가 메모리 공간에 매핑 된 프로세스를 확인할 수 있습니다.
Thomas Nyman

1
@Gabe 물론, 이것이 재부팅해야 할 이유가 충분하다는 데 동의하지만 OP는 명시 적으로 재부팅이 더 편리한 경우를 요구 하지 않지만 재부팅이 절대적으로 필요한 경우 입니다.
Thomas Nyman

0

소프트웨어 구성의 계획된 변경을 의미하고 완벽하게 작동하는 하드웨어 (아직 보지 못함) 및 버그가없는 소프트웨어 (알다시피 ...)를 가정한다면 커널이나 드라이버의 버그만 강제로 재부팅하십시오. :)

그 외에는 ... init단일 사용자 모드로 전환하지 않고 대체 할 수 있는지 확실 하지 않으며 재부팅과 크게 다르지 않은 마법을 수행합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.