나는 Debian(squeeze)을 실행하는 네트워크에 12대 정도의 단일 보드 컴퓨터를 가지고 있으며 ssh를 통해 액세스합니다(ssh 서버는 dropbear입니다). 이 컴퓨터의 하드웨어에 대한 아이디어를 제공하기 위해 1.2GHz x86 프로세서, 1GB RAM 및 ext2로 포맷된 4GB 플래시 드라이브(저널링으로 인한 추가 플래시 쓰기 스트레스를 방지하기 위해 ext3을 피했습니다), 스왑 파티션도 있습니다. 운전.
일반적으로 제가 사용하는 설정은 훌륭하게 작동하며 모든 컴퓨터에 액세스할 수 있습니다. 때때로 하나는 액세스를 방지합니다. SSH(퍼티)를 통해 연결을 시도하면 로그인 프롬프트가 표시되고, 사용자 이름과 비밀번호를 입력하면 '액세스 거부'라고 응답하고 ~/.ssh/authorized_keys의 공개 키도 거부됩니다. 이전에 작업한 대로 자격 증명이 정확합니다. 컴퓨터는 핑에 응답하고 퍼티는 서버 공개 키를 인식합니다. 이는 시스템이 여전히 실행 중임을 의미합니다. 서버를 다시 시작하면 문제가 해결되어 다시 로그인할 수 있습니다. (지금 루트 crontab에 shutdown -r을 넣는 임시 수정을 시도했지만 정지가 발생하면 안정적으로 실행되지 않는 것 같습니다.) 일단 다시 시작하면 시스템 로그에 정보가 없는 것 같습니다. 무슨 일이 일어났는지 나타내기 위해 로그는 마치 시스템이 충돌한 것처럼 해당 기간 동안 비어 있습니다.
작동이 중지된 것처럼 보이는 일부 사용자 정의 소프트웨어가 시스템에서 실행 중입니다(이것이 바로 SSH를 통해 시작하고 싶었던 이유입니다). 나는 이 프로그램이 문제의 원인이라고 가정하고 있지만 그것이 어떻게 문제를 일으키고 무슨 일이 일어나고 있는지 디버깅하는 방법을 확신하지 못합니다.
내가 생각할 수 있는 가장 그럴듯한 설명은 다른 프로그램에 메모리 누수가 있어서 사용 가능한 메모리가 충분하지 않기 때문에 dropbear가 새 로그인 셸을 생성하지 못하게 하고 crontab이 종료를 실행하지 못하게 한다는 것입니다. 그러나 작동 중인 다른 컴퓨터의 메모리 사용량을 살펴보면 누수를 나타내는 의미 있는 메모리 증가가 없는 것 같습니다(매우 크고 빠르게 작동하며 드물게 누수가 발생하지 않는 한). 나는 OS에 메모리가 부족해지면 시스템을 다시 시작하거나 프로세스를 종료할 것이라고 생각합니다(Linux 커널이 다시 시작되는 것이 맞나요?). 제가 궁금한 또 다른 점은 플래시 드라이브를 사용하고 있다는 사실이 특히 스왑 파티션(플래시 마모를 방지하기 위해 제거해야 한다고 생각함)에 어떤 영향을 미칠 수 있는지 여부입니다. 그러나 플래시 드라이브는 아직 젊습니다(~ 1개월) 아직은 마모가 요인이 될 것이라고 생각하지 않습니다.
메모리 누수 또는 제가 생각하지 못한 다른 원인으로 인해 이러한 증상이 발생할 수 있는지 아는 사람이 있습니까? 그리고 문제를 디버그하고 무엇이 잘못되었는지에 대한 자세한 정보를 알아내는 방법을 아는 사람이 있습니까?
답변1
문제는 제가 사용하고 있던 특정 플래시 드라이브와 관련이 있는 것으로 밝혀졌습니다. 그들은 완전히 제거되지 않으면 Linux에서 문제를 일으킬 수 있는 특별한 'U3' 정크를 가지고 있었습니다. 어쨌든 좀 더 '라이브' 유형의 설치로 전환하는 것이 더 나을 것이라고 결정했습니다. 이제 부팅 시 루트 파일 시스템을 RAM으로 전송하고 거기서 실행하므로 시스템이 계속 실행되는 데 플래시 드라이브가 중요하지 않습니다.