在Kubernetes中运行C/Unix程序：exit(0)无法终止进程

你的问题核心是：Kubernetes容器中，C程序的工作进程捕获到SIGTERM信号后，信号处理器执行完所有清理逻辑并输出了终止日志，但进程仍未退出，而本地运行正常。

可能的原因及对应排查/解决方法 #

1. exit(0) 的清理操作卡住进程 #

exit(0) 会执行所有通过 atexit() 注册的清理函数，同时刷新所有标准IO缓冲区。如果这些清理操作中存在阻塞或死锁，进程会卡在退出流程中。

解决方法：
将信号处理器中的 exit(0) 替换为 _exit(0)。_exit(0) 是系统调用级别的直接终止，不会执行用户态的清理逻辑，能快速终止进程。如果替换后进程正常退出，说明是 exit() 的清理步骤出了问题，需要排查 atexit 注册的函数或IO缓冲区刷新逻辑。

2. 工作进程是容器内的PID 1进程 #

在Kubernetes容器中，如果你的程序是直接作为ENTRYPOINT启动的，它会成为PID 1进程。Linux系统中，PID 1进程默认会忽略未显式处理的信号，且信号处理行为与普通进程不同（比如不会自动转发信号给子进程）。

排查方法：
进入容器执行 ps aux，查看工作进程的PID是否为1。

解决方法：

• 使用tini作为容器的init进程，让你的程序以非PID 1运行。修改Dockerfile的ENTRYPOINT：

  ENTRYPOINT ["tini", "--", "./your-program"]
  

• 如果不想引入外部工具，确保PID 1进程的信号处理逻辑完全覆盖所需信号，且在信号处理器中明确处理所有退出流程。

3. 工作进程存在未终止的线程 #

如果工作进程内有线程阻塞在不可中断的系统调用（比如accept()、read()、sleep()），且该系统调用未被信号打断，可能导致进程无法立即退出。虽然exit(0)会终止所有线程，但如果线程处于内核态的阻塞操作，可能会延迟退出，甚至卡住。

排查方法：
进入容器执行 pstack <工作进程PID>，查看线程的调用栈，确认是否有线程阻塞在某个系统调用。

解决方法：

• 使用sigaction()安装信号处理器时，不要设置SA_RESTART标志。这样当信号触发时，被打断的系统调用会返回EINTR错误，线程可以检测到错误并退出循环。示例代码：

  struct sigaction sa;
  memset(&sa, 0, sizeof(sa));
  sa.sa_handler = handle_sigterm;
  // 不设置SA_RESTART，让系统调用被信号打断后返回EINTR
  sigaction(SIGTERM, &sa, NULL);
  

• 将阻塞的系统调用替换为可响应信号的方式，比如用select()/poll()替代sleep()，或者在accept()等调用中处理EINTR错误，主动退出线程。

4. 信号处理器中的清理操作隐含问题 #

虽然你看到了最后一条日志，但清理步骤（如close()、free_manipulation_table()）可能存在隐性错误，比如重复关闭文件描述符、释放已释放的内存，这些操作可能触发未被捕获的信号，导致进程进入异常状态而非正常退出。

排查方法：
在清理步骤中添加错误检查，比如：

#include <string.h>
#include <errno.h>

// ...

if (close(connfd) == -1) {
    error_msg(sip_man_log, "(MAIN) ERROR: Failed to close connfd: %s", strerror(errno));
}

确认所有清理操作都能正常完成。

内容的提问来源于stack exchange，提问作者dennis_10-33