SIGTERM与SystemExit正确使用问题：异步模型训练终止异常

你的代码出现不稳定的核心原因是异步环境下错误使用同步信号处理机制，再加上异步任务生命周期不受控、阻塞事件循环等问题，导致信号处理行为完全不可预测。以下是具体问题点和对应修复方法：

1. 同步信号处理与异步事件循环冲突 #

你通过signal.signal注册的同步信号处理函数，会在独立的信号处理线程中执行，而非asyncio的事件循环线程。这会引发两个关键问题：

• raise SystemExit无法正确终止异步任务，因为信号线程的异常不会传递到事件循环的任务上下文；
• 同步执行obj.train_final_model()会阻塞信号线程，甚至可能和事件循环中的训练操作产生资源竞争，导致"模型找不到"的错误。

修复方法：使用asyncio原生的asyncio.add_signal_handler注册异步信号回调，确保信号处理逻辑在事件循环中执行：

import asyncio
import signal

async def func1():
    obj = modelobj()
    loop = asyncio.get_running_loop()
    
    async def termination_handler():
        # 在事件循环上下文执行收尾逻辑
        obj.train_final_model()
        print("Training done !")
        # 停止事件循环，触发优雅退出
        loop.stop()
    
    # 注册SIGTERM的异步处理回调
    loop.add_signal_handler(signal.SIGTERM, lambda: asyncio.create_task(termination_handler()))
    
    try:
        # 若train_models是同步阻塞函数，放到线程池执行避免卡住事件循环
        await loop.run_in_executor(None, obj.train_models)
        await asyncio.sleep(1)
    except Exception as e:
        print(e)
    finally:
        print("All models trained !")

2. 异步任务生命周期不受控 #

你用asyncio.ensure_future启动func1()后，没有跟踪任务状态，FastAPI接口返回后，该任务可能被Python垃圾回收机制回收，导致obj实例被销毁，进而出现"模型找不到"的错误。

修复方法：将任务实例存储到全局变量或FastAPI的app状态中，保持引用避免被回收：

# 全局集合存储训练任务，防止被GC回收
training_tasks = set()

@app.post("/models")
async def model_training():
    task = asyncio.create_task(func1())
    training_tasks.add(task)
    # 任务完成后自动从集合中移除
    task.add_done_callback(training_tasks.discard)
    await asyncio.sleep(1)
    return "OK"

3. 同步训练阻塞事件循环 #

如果obj.train_models()是同步的长耗时操作，会完全阻塞asyncio的事件循环，导致信号处理回调无法及时执行，甚至根本无法触发，出现"收到SIGTERM后仍继续训练"的情况。

修复方法：用loop.run_in_executor把同步训练逻辑放到线程池执行，让事件循环保持响应：

# 在func1中替换原有的obj.train_models()调用
await loop.run_in_executor(None, obj.train_models)

如果是CPU密集型训练，也可以使用进程池，但线程池对IO密集或GIL释放的计算密集场景都适用。

4. Gunicorn与Uvicorn的优雅退出配置 #

Gunicorn默认收到SIGTERM后，会给worker发送SIGTERM并等待30秒后强制杀死。如果你的收尾逻辑需要更长时间，需调整gunicorn启动参数：

# 启动命令添加参数，设置优雅超时时间为120秒（根据实际训练时长调整）
gunicorn main:app --workers 4 --worker-class uvicorn.workers.UvicornWorker --graceful-timeout 120 --timeout 120

确保worker有足够时间完成train_final_model()的执行。

内容的提问来源于stack exchange，提问作者ARIJIT SINGH