Amazon [Ec2 Linux 인스턴스] 열려 있는 파일/파일 설명자(FD)를 추가한 후 SSH가 작동하지 않습니다.

설명자 제한이 변경된 파일을 편집한 후 수행한 다른 작업을 명확히 설명해 주시겠습니까? 파일을 수정하는 것 자체로는 아무 것도 변경되지 않으며 아무런 영향도 미치지 않습니다. 예를 들어, 파일의 다른 곳에 다른 문자를 입력한 경우 변경 사항이 올바르지 않을 수도 있습니다.

특히 다음 사항을 명확히 해주실 수 있나요?

• 나중에 그만뒀나요?
• 재부팅을 시작하시겠습니까?

여부는 확실하지 않습니다.

• 관리 콘솔에서 다시 시작해 보셨나요?
• 문제와 일치하는 네트워크 문제가 있는지 확인해 보셨나요?
• 다른 곳(다른 IP)에서 로그인을 시도하셨나요?

모든 것이 제대로 작동하고 다른 방법으로는 시스템으로 돌아갈 수 없는 경우 다음 AWS 설명서를 따르십시오.액세스할 수 없는 Linux 인스턴스를 복구하는 방법.

가상 하드 드라이브를 새 시스템의 새 드라이브로 교체하고 새 시스템의 "오래된" 하드 드라이브를 조사하여 그 과정에서 중요한 모든 것을 회수하는 것 같습니다.이전 로그 보기 포함시스템에 실제로 어떤 영향이 미치는지 확인하세요.

고쳐 쓰다- 앞서 한도를 늘렸을 때도 비슷한 일이 일어났다는 댓글이 있었습니다. 방금 최대 nofile설정이 1048576(예: 1024*1024, 2^20)인지 테스트하고 다른 곳에서 힌트를 찾았습니다. Linux 상자에서 더 높은 값을 사용하면 가장 높은 1024로 되돌아가지만 문제가 발생하지 않습니다. 어쩌면 당신은 관대하지 않고 제한을 초과하거나 잘못된 제한을 설정하지 못한 것을 치명적으로 간주하여 계속 로그인할 수 없는 AWS 배포판을 사용하고 있을 수도 있습니다.

참고 - 변경 사항은 즉시 적용되지 않습니다. 다음에 로그인할 때 및/또는 새로 로그인한 세션에서 다시 시작한 모든 프로세스 또는 다시 시작한 후 모든 프로세스에 적용되지만 너무 늦었습니다.

문제를 재현할 수 없기 때문에 상자에 어떻게 계속 액세스할 수 있는지 잘 모르겠습니다. 재부팅하지 않으면 루트로 sftp가 작동할 수도 있지만 재부팅 후에는 그 가능성이 사라질 수 있습니다.

su다음번에는 루트로 로그인할 수 없거나 다시 사용할 수 없는 경우를 대비하여 루트 SSH 세션 실행 화면을 활성 상태로 유지하는 것이 좋습니다 . 어쩌면 mosh를 통해 연결되었을 수도 있습니다. 이는 향후 로그인에 영향을 미치는 시스템 내용을 변경할 때 중요할 수 있습니다.

돌아갈 수 없는 경우를 대비하여 이전 파일을 복원하기 위해 30분 후에 cronjob을 예약하는 것을 고려할 수도 있습니다. 그러나 이러한 파일은 변경 자체 전에 준비되어야 하며 실행이 차단될 수 있습니다.

안타깝게도 원격 액세스 방법 중 어느 것도 작동하지 않는 경우(sftp를 루트로 사용하는 것은 좋지 않은 생각임) 위에 링크된 AWS 설명서를 참조하여 다른 인스턴스를 통해 호스트의 데이터를 복원해야 할 수도 있습니다.

EC2 AMI와 관련된 문제인 것 같습니다. 이 문제를 해결하려면.

1. EC2 인스턴스에서 EBS 분리
2. fs.nr_open = 4000000추가하다/etc/security/limits.conf fs.file-max = 4000000 fs.nr_open = 4000000
3. EBS를 EC2 인스턴스에 연결
4. EC2를 다시 시작하고 로그인하세요.