Linux环境下IdTCPServer客户端间歇性断连失败问题求助

排查解决思路 #

1. 优先验证死锁问题 #

你观察到的卡在FConnectionHandle.Enter的现象本质是临界区死锁，可通过以下方式快速确认：

• 程序运行异常时用gdb attach [进程ID]挂载进程，执行info threads查看所有线程状态，再用thread apply all bt打印所有线程的调用栈，即可直接定位到持有FConnectionHandle锁且未释放的线程。
• 若进程已经退出，提前开启系统coredump生成配置（执行ulimit -c unlimited，并配置内核core_pattern路径），崩溃后通过coredump分析锁持有状态。

2. 修复你现有DisconnectClient逻辑的死锁隐患 #

你当前的实现中，持有Contexts全局列表锁的期间调用CloseSocket是最可能的死锁诱因：
IdTCPServer的Contexts全局锁是用来保护列表增删改查的，你拿着这把锁去等单个Socket的FConnectionHandle锁；而如果此时该Socket对应的工作线程（执行OnExecute逻辑的线程）刚好持有FConnectionHandle锁，同时又尝试申请Contexts全局锁操作列表，就会形成双向等待的死锁，两边永远无法继续执行。

修复方法：将断连操作移出锁范围，仅在持有锁的期间获取目标Context的引用（或复制需要的参数），释放全局锁后再执行断连：

// 锁内仅获取Context指针，不执行断连
var
  TargetContext: TIdContext;
begin
  TargetContext := nil;
  // 加锁操作列表
  List := IdTCPServer1.Contexts.LockList;
  try
    // 遍历查找目标Context，赋值给TargetContext
    // ... 原有查找逻辑
    if Index >=0 then TargetContext := List[Index];
  finally
    // 先释放全局列表锁
    IdTCPServer1.Contexts.UnlockList;
  end;

  // 锁释放后再执行断连，避免锁竞争
  if Assigned(TargetContext) then
  begin
    try
      TargetContext.Connection.Socket.Binding.CloseSocket;
    except
      // 捕获断连异常打日志即可
    end;
  end;

3. 排查临界区未释放的边界场景 #

• 检查你修改的Indy源码中，所有FConnectionHandle.Enter的位置是否都有对应的finally块执行Leave，有没有分支逻辑抛出异常后跳过了Leave调用。
• Linux环境下Socket操作会触发SIGPIPE信号，默认行为是直接杀死进程，如果线程持有临界区时收到SIGPIPE直接退出，就会导致临界区永远无法被释放。你需要注册信号处理函数捕获SIGPIPE、SIGSEGV、SIGABRT等信号，打日志后再优雅退出，避免进程直接消失。

4. 优化断连逻辑避免硬关Socket #

外部线程硬关Socket的方式本身就容易触发资源竞争，更安全的实现是用标记位让工作线程自己退出：

• 你已经在自定义Context里加了TryDisconnect计数，直接在OnExecute事件的循环开头判断如果TryDisconnect>0就直接退出循环，Indy会自动释放该Context的所有资源，不需要外部调用CloseSocket。
• 确有必要调用断连API时，优先用TIdContext.Connection.Disconnect(False)，参数False代表不等待工作线程退出，直接触发断连逻辑，比直接关Socket更符合Indy的生命周期设计。

5. 进程无日志退出排查 #

Linux下无日志直接退出90%以上是触发了未处理的信号，除了开启coredump之外，你可以用strace -p [进程ID]跟踪运行中的进程系统调用，异常退出时就能看到最后收到的信号类型，快速定位退出原因。

内容的提问来源于stack exchange，提问作者Bart Kindt