나는 수년 동안 매일 Linux 시스템을 사용해 왔으며 시스템이 실행되는 동안 시스템을 업데이트하는 데 큰 문제가 발생한 적이 없지만 여전히 왜 이런 일이 발생하는지 궁금합니다.
예를 들어 보겠습니다.
특정 패키지의 프로그램 "A"가 시스템에서 실행되고 있다고 가정합니다. 어느 시점에서 프로그램은 동일한 패키지에 있는 다른 파일("B")을 열어야 합니다. 그 후에 프로그램 "A"는 더 이상 필요하지 않기 때문에 "B"를 종료합니다. 이제 "A"와 "B"가 속한 패키지를 업데이트한다고 가정해 보겠습니다. "A"는 RAM에서 실행되고 업데이트가 단순히 하드 드라이브의 "A"를 대체하기 때문에 적어도 현재로서는 이 작업의 직접적인 영향을 받지 않습니다. 파일 시스템의 "B"도 교체되었다고 가정합니다. 이제 어떤 이유로 "A"는 "B"를 다시 읽어야 합니다. 문제는 "A"가 "B"의 호환되지 않는 버전을 찾아서 충돌하거나 오작동하는 것이 가능합니까?
Live CD나 유사한 프로그램을 사용하여 재부팅하여 시스템을 업데이트하지 않는 이유는 무엇입니까?
답변1
사용자 공간 업데이트는 거의 문제가 되지 않습니다.
다음과 같은 이유로 라이브 시스템에서 패키지를 자주 업데이트할 수 있습니다.
- 공유 라이브러리는 호출할 때마다 디스크에서 읽히지 않고 메모리에 저장되므로 애플리케이션을 다시 시작할 때까지 이전 버전이 계속 사용됩니다.
- 열린 파일은 실제로 다음에서 가져온 것입니다.파일 설명자, 따라서 이동/이름 변경/삭제된 경우에도 섹터를 덮어쓰거나 파일 설명자가 닫힐 때까지 실행 중인 응용 프로그램에서 파일 내용을 계속 사용할 수 있습니다.
- 패키지가 잘 디자인된 경우 다시 로드하거나 다시 시작해야 하는 패키지는 일반적으로 패키지 관리자가 올바르게 처리할 수 있습니다. 예를 들어 데비안은 libc6이 업그레이드될 때마다 특정 서비스를 다시 시작합니다.
일반적으로 커널을 업데이트하고 ksplice를 사용하지 않는 경우 업데이트를 활용하려면 프로그램이나 서비스를 다시 시작해야 할 수도 있습니다. 그러나 데스크톱에서는 개별 서비스를 다시 시작하는 것보다 더 쉬울 때도 있지만 사용자 공간의 항목을 업데이트하기 위해 시스템을 다시 시작할 필요는 거의 없습니다.
당신은 또한 볼 수 있습니다
http://en.wikipedia.org/wiki/Ring_%28computer_security%29#Supervisor_mode
답변2
예, 설명하신 내용은 가능합니다. 하지만 대부분의 경우 파일이 패키지에 포함된 경우 한 번만 읽히는 라이브러리나 기타 파일이 됩니다(변경되지 않으므로 여러 번 읽을 이유가 없습니다). 타임스). 또한 파일이 장기간 필요한 경우 응용 프로그램은 파일 핸들을 열어 둘 수 있습니다. 여기서 열린 파일 핸들은 실제 파일 시스템에서 교체되더라도 이전 버전을 열어 둡니다.
대부분의 경우 프로세스 수명 주기 동안 여러 번 읽히는 데이터는 사용자/변수 데이터이며 패키지 업그레이드 중에 변경되지 않습니다. 또한 데이터는 변경 가능하므로 올바른 생각을 가진 프로그래머라면 프로그램이 한 읽기에서 다음 읽기까지의 변경 사항을 처리할 수 있는지 확인해야 합니다.
답변3
파일 시스템의 "B"도 교체되었다고 가정합니다. 이제 어떤 이유로 "A"는 "B"를 다시 읽어야 합니다. 문제는 "A"가 "B"의 호환되지 않는 버전을 찾아서 충돌하거나 오작동하는 것이 가능합니까?
이는 가능하지만 대부분의 경우 가능성은 낮습니다. "B"가 코드 베이스인 경우 원래 버전은 일반적으로 닫히지 않습니다. "A"는 "B"의 원래 버전을 계속 사용합니다. 업데이트 후 "A"를 실행하면 새로운 버전의 "B"가 사용됩니다. 업데이트 중에 호환되지 않는 버전이 로드될 위험이 있습니다. 그러나 코드베이스가 로드되는 방식으로 인해 "A"에 로드되는 "B" 버전에 없는 기능이 필요한 경우에만 문제가 됩니다.
좋은 코딩 습관은 기능적 인터페이스를 동일하게 유지합니다. 따라서 새 버전에서 버그가 수정되지 않는 한 어떤 버전이 로드되는지는 중요하지 않습니다.
구성 파일의 상황은 약간 다르지만 일반적으로 시작 중에 읽혀집니다. 이 경우 구성 변경 사항을 다시 로드하지 않으면 "A"는 "B"를 읽지 않습니다. 마찬가지로 구성 파일의 형식이나 의미를 변경하는 것은 잘못된 코딩 습관입니다. 호환되지 않는 구성 파일 버전은 문제를 일으키지 않도록 다른 이름을 가져야 합니다.
Live CD나 유사한 프로그램을 사용하여 재부팅하여 시스템을 업데이트하지 않는 이유는 무엇입니까?
종료했다가 다른 버전에서 다시 시작하면 서비스가 중단될 수 있습니다. 이는 일반적으로 서버에 바람직하지 않습니다. 그럼에도 불구하고 실행 중인 시스템의 패키지 관리자는 설치된 소프트웨어와 버전을 알고 있습니다. Live CD에는 설치된 소프트웨어의 자체 목록이 있으며 버전이 다를 수 있습니다. 이로 인해 Live CD에서 실행 중인 시스템을 안정적으로 업그레이드하기가 어렵습니다.
새 버전의 운영 체제를 설치할 때 Live CD가 사용되는 경우가 있습니다. 이 경우 일반적으로 운영 체제 새로 설치가 완료됩니다. 이는 유지되는 이전 버전의 사용되지 않은 파일 수를 제한합니다. 이는 라이브 시스템을 업그레이드하는 것보다 더 힘들 수 있습니다. 그러나 다른 루트 파티션을 사용하면 부분적으로 업데이트된 시스템이 부팅되지 않아 정체될 위험을 제한할 수 있습니다.
답변4
이는 다음과 같은 경우에 문제가 됩니다.
- java-VM 런타임을 위한 JDK 업그레이드: 저도 같은 질문을 스스로에게 했습니다. java를 사용하여 실행 중인 tomcat이 있습니다. 이제 JDK를 패치한 후에도 여전히 잘 실행되는 것 같습니다.
현재 설명은 캐싱입니다. 좋습니다. 사용 가능한 RAM을 모두 소모하는 메모리 호그를 시작했습니다. 그런 다음 Tomcat이 충돌했습니다(여기에서 실행 중인 애플리케이션에 액세스한 후).
- SuSE 시스템의 커널 업그레이드: SuSE에서는 커널 패치 업그레이드 후 이전 커널과 해당 모듈이 즉시 제거됩니다. 지금까지 로드되지 않은 커널 모듈이 필요한 새로운 것을 사용하려는 경우 서비스가 실패합니다.