방화벽 뒤의 NFS 공유로 인해 프로세스가 D 상태에 멈춰 있는 문제가 종종 발생합니다. 연결이 끊어지면 프로세스가 D 상태에 걸리고 종료할 수 없습니다. 유일한 해결책은 하드 재부팅입니다. 다른 방법이 없을까 고민했지만 제가 찾아낸 해결책과 정보는 모두 "그냥 죽일 수는 없다"는 것뿐이었습니다. 모두가 현상 유지를 받아들이고 받아들이는 것 같습니다. 나는 이에 대해 다소 비판적이다. 프로세스를 다시 시작할 필요가 없도록 메모리에서 프로세스를 긁어내는 방법이 있어야 한다고 생각합니다. 이런 일이 자주 발생하면 매우 짜증날 수 있습니다. 리소스가 IO를 반환하는 경우 이 경우 간단히 무시할 수 있습니다. 왜 이것이 불가능합니까? IMHO, Linux 커널은 매우 발전되어 있으므로 이와 같은 작업을 수행할 수 있어야 합니다. 특히 서버에서는...
만족스러운 답변을 찾을 수 없습니다. 왜 구현되지 않거나 구현될 수 없나요?
나는 또한 이 질문을 설명할 수 있는 프로그래밍과 알고리즘의 본질에 대한 답변에도 관심이 있습니다.
답변1
시스템 호출로 프로세스를 종료하는 것이 가능하며 대부분의 경우 작동합니다. 어려운 부분은 항상 작동하도록 만드는 것입니다. 99.99%에서 100%로 가는 것은 어려운 부분입니다.
일반적으로 프로세스가 종료되면 해당 프로세스에서 사용된 모든 리소스가 해제됩니다. 프로세스에서 I/O가 진행 중인 경우 I/O를 수행하는 코드에 알림이 전송되고 종료되어 사용 중이던 리소스가 해제됩니다.
중단되지 않는 절전 모드는 "코드가 통보되고 종료되는" 데 무시할 수 없는 시간이 걸릴 때 눈에 띄게 발생합니다. 이는 코드가 제대로 작동하지 않음을 의미합니다. 이것은 실수입니다. 예, 이론적으로는 버그 없는 코드를 작성하는 것이 가능하지만 실제로는 불가능합니다.
"리소스가 IO를 반환하는 경우 간단히 무시할 수 있습니다"라고 말합니다. 알았어 알았어. 그러나 주변 장치가 다음과 같이 프로그래밍되었다고 가정합니다.메모리에 쓰기프로세스에 속합니다. 주변 장치에 대한 요청을 취소하지 않고 프로세스를 종료하려면 메모리 사용량을 어떻게든 유지해야 합니다. 리소스를 직접 제거할 수는 없습니다. 일부 자원은 귀하에게 남아 있어야 합니다. 커널이 어떤 리소스를 해제해도 안전한지 아는 경우에만 다른 리소스를 해제할 수 있습니다. 이를 위해서는 항상 구별할 수 있는 방식으로 코드를 작성해야 합니다. 방해받지 않는 수면이 상당한 시간 동안 지속되는 상황은 판단하기 불가능하며, 유일한 안전한 방법은 이를 피하는 것입니다.
종료 프로세스가 작동하도록 보장하는 운영 체제를 설계하는 것이 가능합니다(하드웨어가 제대로 작동한다는 특정 가정 하에서). 예를 들어, 하드 실시간 운영 체제는 프로세스 종료에 최대 특정 고정 시간이 소요되는 것을 보장합니다(종료 기능을 제공한다고 가정). 그러나 이는 어려운 일이며, 특히 운영 체제가 광범위한 주변 장치를 지원하고 우수한 공통 성능을 제공해야 하는 경우에는 더욱 그렇습니다. Linux는 여러 면에서 최악의 동작보다 일반적인 동작을 선호합니다.
모든 코드 경로를 포괄하는 것은 매우 어렵습니다. 특히 첫날부터 이를 수행할 엄격한 프레임워크가 없는 경우에는 더욱 그렇습니다. 전반적으로, 종료할 수 없는 프로세스는 극히 드뭅니다. 발생하지 않는 경우에는 알 수 없습니다. 이는 오프로드 차량 운전자의 증상입니다. Linux 드라이버를 작성하는 데는 제한된 노력이 투입되었습니다. 장기간 중단 없이 잠을 자는 경우를 더 많이 없애려면 작업을 수행하는 데 더 많은 사람이 필요하거나 하드웨어 지원이 줄어들고 성능이 저하됩니다.