가득 찬 스왑 파티션으로 인해 Linux에서 파일 잠금 문제가 발생할 수 있습니까?

가득 찬 스왑 파티션으로 인해 Linux에서 파일 잠금 문제가 발생할 수 있습니까?

집에 아주 작은 RAM으로 기본 OS 0.2를 실행하는 컴퓨터가 있는데, 스왑은 항상 거의 가득 찼습니다. (가능한 한 빨리 RAM을 업그레이드하겠습니다.) 공개 키 인증으로 OpenSSH 서버가 설정되어 있습니다. 오늘 로그인 했더니 비밀번호를 물어보더라구요. 내 공개 키를 원격 Authorized_keys 파일에 다시 지정했고 공개 키 인증이 다시 작동하기 시작했습니다. 내 추측으로는 내가 파일에 썼을 때 해제된 파일에 잠금이 있었던 것 같습니다.

이 상황을 올바르게 해석하고 있습니까? 문제의 원인은authorized_keys 파일에 대한 잠금입니까? 그리고 전체 스왑 파티션으로 인해 파일 잠금 문제가 발생할 수 있습니까?

답변1

안타깝게도 귀하의 질문은 애플리케이션에 따라 다르며 시나리오/상황에 따라 다릅니다. 간단히 대답하자면, '아니요'입니다(또는 오히려 그렇게 하면 안 됩니다).

스왑 파티션은 RAM의 확장으로 표시되어야 합니다. SWAP이 가득 차는 것을 방지하려면 (더 많은 RAM을 확보하기 전에) SWAP 파티션을 더 크게 만들 수 있습니다. 그러나 더 많은 RAM도 얻으십시오. SWAP은 RAM보다 1000배 느릴 수 있습니다.

따라서 귀하의 질문에 완전히 대답하려면 다음 질문을 하십시오. RAM이 부족하면 PC(및 실행 중인 응용 프로그램)에 어떤 일이 발생합니까? 아니면 RAM과 SWAP?

새 응용 프로그램 시작을 거부합니다... 메모리를 요청하는 응용 프로그램에 새 메모리 블록 제공을 거부합니다(이러한 응용 프로그램이 이러한 거부로부터 복구할 수 있는 경우 오류를 기록하고 계속 실행되며 대부분의 응용 프로그램이 중단되거나 메모리를 할당할 수 없으면 목적을 달성할 수 없으므로 정상적으로 종료합니다.

따라서 키 파일이 실제로 잠긴 경우(이런 일이 발생했을 수 있음) SSH/SSL 관련 문제로 인해 메모리를 할당할 수 없어 데몬이 정지되거나 데몬이 다시 시작되는 경우일 가능성이 높습니다. 위에서 언급한 이유.

openssh-server를 사용하는 경우 비밀번호 인증을 허용하지 않도록 /etc/ssh/sshd_conf를 변경하고 RAM이 0이고 SWAP 공간이 0인 시나리오를 재현해 보십시오. 솔직히 말해서 sshd가 충돌할 것이라고 생각합니다.

관련 정보