☰

Amazon [Ec2 Linux 实例] 增加打开文件/文件描述符 (FD) 后 SSH 不起作用

tag-icon • tag-icon linux ssh amazon-ec2 ulimit
Amazon [Ec2 Linux 实例] 增加打开文件/文件描述符 (FD) 后 SSH 不起作用

ssh执行以下命令后，我无法访问我的 ec2 实例 [基于 Linux]。 [在此之前我可以通过 ssh 连接到服务器]

# vim /etc/sysctl.conf

我已将文件最大数量更新为 4000000

fs.file-max = 4000000

我还编辑过：

# vi /etc/security/limits.conf

在末尾添加以下行

* soft nofile 4000000 * hard nofile 4000000

然后我退出 ec2 insatnce 并再次尝试 ssh 但没有运气。

我尝试过使用 -v 选项进行 ssh，我得到的只是

debug1: Exit status 254

注意：这是我所做的唯一更改。

答案1

您能否澄清一下，在编辑描述符限制更改的文件后，您还做了什么？就其本身而言，修改文件不会改变任何内容，并且应该不会产生任何影响。更改甚至可能不正确，例如，如果在文件中的其他位置输入了不同的字符。

特别是，您能否澄清一下：

  • 你后来退出了吗？
  • 启动重启？

也不清楚是否

  • 您是否尝试过从管理控制台重新启动？
  • 您是否尝试过查看是否存在与您的问题一致的网络问题？
  • 您是否尝试过从其他地方（不同的IP）登录？

如果一切正常，并且您无法以任何其他方式返回系统，您可能需要按照以下 AWS 文档进行操作：如何恢复无法访问的 Linux 实例。

它似乎是用新系统的新硬盘替换虚拟硬盘，并从新系统中调查“旧”硬盘，抢救过程中的任何重要内容，包括查看旧日志看看对系统的实际影响是什么。

更新- 早些时候有评论表明在增加限制时也发生了类似的事情。我刚刚测试（并在其他地方找到了提示）最大nofile设置是1048576（即 1024*1024，2^20）。如果我在我的 Linux 机器上使用任何更高的值，它只会恢复到最高的 1024，但不会造成问题。也许您使用的 AWS 发行版并不那么宽容，要么会超出限制，和/或认为设置无效限制的失败是致命的，并且不会让您继续登录。

注意 - 您所做的更改不是即时的。它们在您下次登录时生效，和/或从新登录的会话重新启动的任何进程 - 或重新启动后的所有进程，但这对您来说已经太晚了。

由于我无法重现您的问题，因此我不确定您仍然可以通过什么方式访问您的盒子。如果没有重新启动，也许 sftp 作为 root 可以工作，但重新启动后，这种可能性可能就消失了。

下次，您可能需要考虑保持 root ssh 会话运行屏幕处于活动状态，以防您无法以 root 身份登录或su再次使用。甚至可能通过 mosh 连接。当您更改系统上影响未来登录的任何内容时，这一点可能很重要。

您还可以考虑安排 30 分钟后的 cronjob 来恢复以前的文件，以防您无法返回 - 但这些必须在更改本身之前准备好，并且可能会被阻止运行。

不幸的是，如果没有任何远程访问方法适合您（包括 sftp 作为 root，这不是一个好主意），那么您可能需要参考上面链接的 AWS 文档来恢复主机上的数据通过不同的实例。

答案2

似乎这是与 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并登录

相关内容