실행중인 Linux 시스템을 업데이트하는 데 문제가없는 이유는 무엇입니까?

몇 년 전부터 매일 Linux 시스템을 사용하고 있는데 시스템이 실행 중일 때 시스템을 업데이트해도 큰 문제가 없었지만 이것이 왜 가능한지 궁금합니다.

예를 들어 보겠습니다.

특정 패키지의 프로그램 "A"가 시스템에서 실행되고 있다고 가정하십시오. 특정 시점에서이 프로그램은 동일한 패키지에서 다른 파일 ( "B")을 ​​열어야합니다. 그 후, 프로그램 "A"는 더 이상 필요하지 않기 때문에 "B"를 닫습니다. "A"와 "B"가 속한 패키지를 업데이트한다고 가정하겠습니다. "A"는 RAM에서 실행 중이고 업데이트가 하드 디스크의 "A"를 대체하기 때문에 최소한이 작업의 영향을받지 않습니다. 파일 시스템에서 "B"도 교체되었다고 가정하십시오. 이제 "A"는 어떤 이유로 "B"를 다시 읽어야합니다. 문제는 "A"가 호환되지 않는 "B"버전을 찾아서 다른 방식으로 충돌 또는 오작동 할 가능성이 있습니까?

라이브 CD 나 다른 유사한 절차로 재부팅하여 아무도 시스템을 업데이트하지 않는 이유는 무엇입니까?

Userland 업데이트는 거의 문제가되지 않습니다

다음과 같은 이유로 라이브 시스템에서 패키지를 자주 업데이트 할 수 있습니다.

1. 공유 라이브러리는 각 호출에서 디스크에서 읽지 않고 메모리에 저장되므로 응용 프로그램을 다시 시작할 때까지 이전 버전은 계속 사용됩니다.
2. 열린 파일은 실제로 파일 이름이 아닌 파일 디스크립터 에서 읽으 므로 섹터를 덮어 쓰거나 파일 디스크립터가 닫힐 때까지 이동 / 이름 바꾸기 / 삭제 된 경우에도 실행중인 애플리케이션에서 파일 컨텐츠를 계속 사용할 수 있습니다.
3. 다시로드하거나 다시 시작해야하는 패키지는 일반적으로 패키지가 제대로 디자인 된 경우 패키지 관리자가 올바르게 처리합니다. 예를 들어, 데비안은 libc6을 업그레이드 할 때마다 특정 서비스를 다시 시작합니다.

일반적으로 커널을 업데이트하지 않고 ksplice를 사용하지 않는 경우 업데이트를 이용하려면 프로그램 또는 서비스를 다시 시작해야 할 수 있습니다. 그러나 데스크톱에서는 개별 서비스를 다시 시작하는 것보다 쉬운 경우가 있지만 사용자 영역에서 업데이트하기 위해 시스템을 다시 부팅 할 필요는 거의 없습니다.

참조

http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode

예, 설명 한 것이 가능하지만 대부분 파일이 패키지에 포함 된 경우 한 번만 읽은 라이브러리 또는 다른 파일이됩니다 (변경되지 않기 때문에 이유가 없습니다) 여러 번 읽습니다). 또한 파일이 장기간 필요한 경우 응용 프로그램은 파일 핸들을 열린 상태로 유지합니다. 실제 파일 시스템에서 파일이 바뀌더라도 열린 파일 핸들은 이전 버전을 열린 상태로 유지합니다.

대부분의 경우 프로세스 수명 동안 여러 번 읽은 데이터는 사용자 / 변수 데이터이며 패키지 업그레이드 중에는 변경되지 않습니다. 또한 데이터는 가변적이므로 올바른 프로그래머라면 프로그램이 한 읽기에서 다음 읽기로 변경하는 것을 처리 할 수 ​​있어야합니다.

파일 시스템에서 "B"도 교체되었다고 가정하십시오. 이제 "A"는 어떤 이유로 "B"를 다시 읽어야합니다. 문제는 "A"가 호환되지 않는 "B"버전을 찾아서 다른 방식으로 충돌 또는 오작동 할 가능성이 있습니까?

가능하지만 대부분의 경우는 거의 없습니다. "B"가 코드 라이브러리 인 경우 원래 버전은 일반적으로 닫히지 않습니다. "A"는 원래 버전 "B"를 계속 사용합니다. 업데이트 후 "A"를 실행하면 새 버전의 "B"가 사용됩니다. 업데이트 중에 호환되지 않는 버전이로드 될 위험이 있습니다. 그러나 코드 라이브러리가로드되는 방식으로 인해 "A"가로드 한 "B"버전에없는 기능이 필요한 경우에만 문제가됩니다.

좋은 코딩 방법은 인터페이스와 기능을 동일하게 유지합니다. 결과적으로 최신 버전에서 수정 된 버그가 아닌 경우 어떤 버전이로드되는지는 중요하지 않습니다.

구성 파일은 약간 다르지만 일반적으로 시작하는 동안 읽습니다. 이 경우 구성을 다시로드하지 않으면 "A"는 "B"를 읽지 않습니다. 다시, 구성 파일의 형식이나 의미를 변경하는 것은 나쁜 코딩 관행입니다. 호환되지 않는 구성 파일 버전의 이름은 달라야하므로 문제가 발생하지 않습니다.

라이브 CD 나 다른 유사한 절차로 재부팅하여 아무도 시스템을 업데이트하지 않는 이유는 무엇입니까?

다른 버전에서 시스템을 종료하고 재부팅하면 서비스가 중단 될 수 있습니다. 서버의 경우 일반적으로 바람직하지 않습니다. 어쨌든 실행중인 시스템의 패키지 관리자는 설치된 소프트웨어 및 버전을 인식합니다. 라이브 CD에는 다른 버전의 소프트웨어가 설치되어 있습니다. 따라서 라이브 CD에서 실행중인 시스템을 안정적으로 업그레이드하기가 어렵습니다.

라이브 CD는 때때로 새로운 O / S 릴리스가 설치 될 때 사용됩니다. 이 경우 일반적으로 O / S를 새로 설치합니다. 이전 버전에서 사용하지 않는 파일의 양을 제한 할 수 있습니다. 라이브 시스템을 업그레이드하는 것보다 더 많은 노력이 필요할 수 있습니다. 그러나 다른 루트 파티션을 사용하는 경우 부팅 할 수없는 부분적으로 업데이트 된 시스템에 끼일 위험이 제한 될 수 있습니다.

이것이 문제인 경우가 있습니다.

• java-VM이 실행되는 동안 JDK 업그레이드 : myselv와 동일한 질문을했습니다. java를 사용하는 실행중인 바람둥이가있었습니다. 이제 JDK의 패치 업데이트 후에도 여전히 문제없이 실행되었습니다.

이제 설명은 캐시 메모리입니다. OK-사용 가능한 모든 RAM을 사용하기 위해 메모리 호그 프로그램을 시작한 다음 Tomcat이 추락했습니다 (내가 실행중인 응용 프로그램에 액세스 한 후).

• SuSE 시스템의 커널 업그레이드 : SuSE에서 커널의 패치 업그레이드 직후에 이전 커널과 해당 모듈이 삭제됩니다. 그런 다음 지금까지로드되지 않은 커널 모듈이 필요한 새로운 것을 사용하려면 서비스가 실패합니다.