运行于Linux systemd的.NET 6应用触发Tasks上限导致重启求助

可能的问题根源 #

• 线程/Task泄漏：手动创建的Thread未正确终止，或者大量Task处于挂起/阻塞状态未被回收。比如循环创建Task但未处理完成状态，或用Task.Run执行无限循环逻辑却无终止条件。
• 异步操作处理不当：存在大量未await的异步任务，导致任务资源（含线程池线程）无法释放；或错误使用同步阻塞调用（如.Result/.Wait()）造成线程池耗尽，进而触发大量Task排队。
• 第三方库资源泄漏：依赖的第三方组件（如数据库驱动、消息队列客户端）内部存在线程或Task泄漏，未正确释放连接或资源。
• 子进程创建失控：应用频繁通过Process.Start创建子进程但未及时回收，每个子进程会占用系统Tasks计数，累积到上限后触发systemd重启。
• systemd配置限制：systemd服务配置中可能设置了TasksMax参数，默认值低于应用实际需求，当进程Tasks数超过该值时，systemd会强制重启服务。

进一步排查需要的信息 #

• systemd服务配置文件（通常在/etc/systemd/system/xxx.service）内容，重点查看TasksMax、LimitNPROC等资源限制参数。
• 应用重启前的日志输出：包括.NET应用自身日志，以及systemd的journal日志（可通过journalctl -u <service-name>查看），尤其关注错误、警告级别的信息。
• 进程接近Tasks上限时的线程/Task快照：用dotnet-dump collect -p <pid>生成转储文件，或用ps -eLf | grep <pid>查看线程数量；也可在代码中添加监控，输出当前活跃Task数。
• 应用中涉及线程、Task、异步操作的核心逻辑片段，比如批量任务处理、后台常驻任务、第三方资源调用的代码。
• 系统资源限制配置：执行ulimit -a和systemctl show <service-name> | grep Tasks的输出，确认当前的Tasks限制值。
• 近期的代码变更或依赖包升级记录，排查是否是某次更新后引入的问题。

内容的提问来源于stack exchange，提问作者Kęstutis Ramulionis