Você pode esclarecer, depois de editar o arquivo para a mudança de limite do descritor, o que mais você fez? Por si só, modificar o arquivo não muda nada e não deve ter efeito. A alteração pode estar incorreta, por exemplo, se um caractere diferente foi inserido em outro lugar no arquivo.
Em particular, você pode esclarecer se
- você fez logout depois?
- iniciou uma reinicialização?
Também não está claro se
- você tentou reinicializar a partir do console de gerenciamento?
- você tentou ver se há algum problema de rede coincidente com seu problema?
- você tentou fazer login em outro lugar (IP diferente)?
Se tudo fizer check-out e você não conseguir voltar ao sistema de outra maneira, talvez seja necessário seguir a documentação da AWS sobre Como recuperar uma instância de Linux inacessível .
O que parece ser é substituir o disco rígido virtual por um novo com um novo sistema e investigar o disco rígido "antigo" de dentro do novo sistema, salvando qualquer coisa importante no processo, incluindo a revisão do disco rígido. logs antigos para ver qual foi o efeito real no sistema.
Atualização - houve um comentário antes para sugerir que coisas semelhantes aconteceram quando o limite foi aumentado. Acabei de testar (e encontrei dicas em outro lugar) que a configuração máxima de nofile é 1048576 (ou seja, 1024 * 1024, 2 ^ 20). Se eu usar algo mais alto na minha caixa Linux, ele será revertido para 1024 como o mais alto, mas não causará nenhum problema. Talvez a distribuição que você está usando para a AWS não seja tão indulgente, e não ultrapasse o limite e / ou considere a falha em definir um limite inválido como fatal e não permita que você continue com o login.
Nota - as alterações que você faz lá não são instantâneas. Eles afetam o próximo login e / ou os processos que você reinicia a partir da sessão recém-conectada - ou para todos os processos após a reinicialização, mas isso já é tarde demais para você.
Como não consigo reproduzir seu problema, não sei ao certo como você ainda pode acessar sua caixa. Talvez sftp como root poderia ter funcionado se não houvesse uma reinicialização, com a reinicialização, essa possibilidade pode ter ido embora.
Para a próxima vez, você pode considerar manter viva uma tela de execução da sessão root ssh, caso não consiga efetuar login como root ou usar su novamente. Talvez até mesmo conectado via mosh. Isso pode ser importante quando você altera qualquer coisa no sistema que afeta logins futuros.
Você também pode considerar um cronjob programado 30 minutos depois para restaurar o arquivo anterior, caso não consiga voltar - mas isso deve ser preparado antes da alteração e pode ser impedido de ser executado.
Infelizmente, se nenhum dos métodos de acesso remoto estiver funcionando (incluindo o sftp como root, o que não é uma boa ideia), talvez seja necessário consultar a documentação da AWS vinculada acima para recuperar os dados. no host por meio de uma instância diferente.