Ssh ***检测到缓冲区溢出***/usr/bin/expect已终止

我正在运行一个tcl脚本，它将ssh会话调用到多个服务器，并使其保持活动状态，以便进行进一步的操作。但在它对1023服务器执行ssh之后，我得到了下面的错误

我对更大的价值设定了软限制和硬限制，但仍然没有运气

下面是服务器limit.conf的详细信息和我尝试过的多个选项

Ulimit-a

核心文件大小（块，-c）0

数据段大小（千字节，-d）不受限制

计划优先级（-e）0

文件大小（块，-f）不受限制

待处理信号（-i）31189

最大锁定内存（KB，-l）64

最大内存大小（千字节，-m）不受限制

打开文件（-n）65536

管道大小（512字节，-p）8

POSIX消息队列（字节，-q）268435456

实时优先级（-r）0

堆栈大小（千字节，-s）8192

cpu时间（秒，-t）不受限制

最大用户进程数（-u）65536

虚拟内存（KB，-v）不受限制

文件锁（-x）无限制

cat/proc/sys/fs/file max

65536

cat/etc/pam.d/login也包含==>所需会话/lib64/security/pam\u限制。因此

尝试了包括链接在内的多种方法

---

请提供帮助。

问题在于您超出了Tcl事件通知程序可以处理的极限，因为它基于

select（）。特别是，它受到堆栈上的结构大小的限制，该结构在编译时设置为（通常）1024个条目，Tcl为其他事情保留了一些文件描述符（例如，标准输入和输出）。这是对FD最大值的限制，而不仅仅是对打开描述符的最大数量的限制。超过最大值会导致堆栈中的缓冲区溢出（以一种难以控制的方式），并触发产生您看到的错误的内存保护代码。（如果使用TCL8.5或8.6，您可能希望
ulimit-n1024
将严重的崩溃转换为更好的崩溃。）

我们在8.7中通过切换到其他没有限制的系统调用（8.7a3上个月发布）解决了这个问题，尽管它是alpha，但它应该足够稳定，适合这种情况。但如果这样做不行，您必须在多个进程之间分配ssh会话的工作负载；如果仍然达到API限制的话，可能每个512个都可以工作，或者是一半？拥有两个或四个管理进程而不是一个（你可以很容易地让一个主进程通过管道控制其他进程）对一般现代计算机来说并不是很大的负载增加。甚至是十年或二十年前的平均水平

在某些情况下，另一种可行的方法是在这些ssh会话中运行screen，这样您就可以断开与它们的连接（而不会丢失正在发生的事情），从而减少同时使用的FD的数量。这不是一个普遍的解决方案
 这里有tcl代码吗？这是什么操作系统？@GeorgeJempty yesI仍然没有看到tcl代码。可能是因为您没有使用代码格式化？您正在创建数百个ssh会话：它们都需要同时打开还是串联运行？您是否在生成的会话上调用
wait
和
close
？有关为修复此问题而更改的内容的详细信息，请参阅