Python中signal.SIGTERM信号的默认行为是直接终止进程，不执行任何清理逻辑。

Python中signal.SIGTERM信号的默认行为是什么

Python进程收到 SIGTERM 时，默认会直接终止，不执行任何清理逻辑。这意味着打开的文件、数据库连接、线程或临时资源可能来不及释放，容易导致数据不一致或残留状态。

关键点在于：Python不会自动帮你做清理，必须显式注册处理函数。

如何用signal.signal()捕获并响应SIGTERM

使用 signal.signal() 绑定自定义函数到 signal.SIGTERM，但要注意几个硬性限制：

• 处理函数只能接受两个参数：signum（信号编号）和 frame（当前栈帧），不能传额外参数
• 处理函数内**禁止调用不可重入函数**（如 print()、logging.info()、sys.exit()），推荐只设标志位
• 主程序需保持运行状态（例如用 while True: 或 time.sleep()），否则信号可能在注册前就已丢失

import signal
import time
running = True
def handle_sigterm(signum, frame):
global running
running = False  # 安全地通知主循环退出
signal.signal(signal.SIGTERM, handle_sigterm)
while running:
time.sleep(1)
此处可做清理：close files, disconnect db, join threads...

为什么不能在信号处理函数里直接清理资源

因为信号可能在任意时刻中断 Python 解释器，此时若在处理函数中调用 I/O、锁操作或 GC 相关函数（比如 logging、print、threading.Lock.release()），极易引发死锁或解释器崩溃。

常见错误现象包括：

橙星梦工厂

风行在线专为漫剧创作者打造的一站式创作与推广平台

• 程序卡住不动，strace 显示阻塞在 futex 或 epoll_wait
• 收到 SIGTERM 后抛出 RuntimeError: reentrant call inside
• 日志只输出一半，或完全没输出

正确做法是仅设置一个线程安全的标志（如全局布尔、threading.Event），让主循环或主线程检测后统一清理。

在多线程程序中处理SIGTERM要注意什么

Linux 中 SIGTERM 只会发送给进程的主线程（即初始线程），其他线程无法直接接收。所以即使你在子线程里调用 signal.signal()，也不会生效。

因此必须确保：

• 信号处理器只在主线程注册（通常就是脚本顶层）
• 所有子线程需支持被外部中断（例如定期检查 running 标志，避免死循环阻塞）
• 若使用 concurrent.futures.ThreadPoolExecutor，应在主循环退出后调用 shutdown(wait=True)

忽略这点会导致主进程退出了，但后台线程仍在跑，进程实际未真正终止。

最易被忽略的是：信号处理函数本身不能做任何“看起来无害”的操作——比如写日志、发 HTTP 请求、甚至调用 os._exit()。平滑退出的关键不在“响应回调”，而在“主流程如何感知并协同退出”。