NSSM 2.24实战：Python脚本Windows服务化与自动重启日志管理

简介：NSSM服务管理器（Non-Sucking Service Manager）的构建版本，面向系统管理员、运维人员及服务开发调试者，用于将任意可执行程序封装为Windows后台服务，解决程序需随系统启动、用户未登录也可持续运行的问题，尤其适合需要长期运行的Web服务、数据库和自研工具等常驻程序。压缩包共40个文件，包含32位与64位的nssm.exe可执行程序，以及15个.h和14个.cpp完整C/C++源码、Visual Studio工程文件、版本脚本、图标资源、说明文档与更新日志；整体仅376KB，Win32与Win64目录划分清晰，结构紧凑。已有429人学习下载。使用时可选用现成工具通过命令行或图形界面把exe注册为服务，配置启动参数、环境变量、日志记录与失败自动重启；也可阅读源码了解服务封装机制，按需定制后自行编译。总体来看，这份资源兼顾日常部署与源码级研究，适合不同层级的Windows服务使用者。

1. NSSM 2.24-101：把脚本交给 Windows 服务管理器前，先搞懂这三件事

NSSM（Non-Sucking Service Manager）是个老牌的 Windows 服务封装工具，2.24-101-g897c7ad 是 2.24 系列里的一个开发构建版本，作用是把普通 exe、bat、python 脚本注册成系统服务，让它们在后台稳定运行、崩溃自动拉起、日志可重定向。之前维护某公司内部运维系统时，一批轮询脚本老是被“计划任务 + 窗口常驻”的方式搞得半死不活，后来统一换成 NSSM 才彻底消停。适合想跑后台任务又不想改代码去写 Windows 服务的那类从业者，也适合给生产环境做服务化封装时不想踩 sc create 那些暗坑的人。这篇把 NSSM 的参数、安装步骤、验证方法和常见翻车点完整拆一遍。

2. 为什么要用 NSSM：sc create、srvany 与 NSSM 的选型对比

2.1 原生 sc create 注册服务的三个尴尬

Windows 自带 sc create 可以把程序注册成服务，但真用起来会碰到很多别扭的地方。最典型的写法是这样：

:: 把 bat 脚本注册成服务（不推荐的写法，仅示范） sc create my-task binPath= "cmd.exe /c D:\scripts\run.bat" start= auto

先说第一个问题：这条命令能注册成功，但服务启动瞬间会退出，因为 cmd.exe 把脚本跑完就结束了，服务状态跟着变成“已停止”。要让它常驻，要么脚本里自己写死循环，要么借助工具，sc 本身没有“进程退出后自动拉起”的能力，脚本崩了就是崩了。第二个问题是输出全部丢进黑洞，脚本里 print 出来的内容、异常堆栈都没地方看，排查问题只能靠猜。第三个问题是路径转义，binPath 里一旦出现空格、引号、斜杠组合，转义规则很容易把人绕进去，经常是注册完启动报 1053 错误，平台日志里什么有效信息都没有。

那这段 sc create 到底适合什么场景？适合临时起一个不需要管死活、不需要看日志的一次性服务。生产环境里的脚本服务化，光靠 sc create 显然不够，后面才去找 NSSM 这类第三方工具。

2.2 NSSM 相对 srvany 的核心能力：自动拉起、日志重定向、GUI 管理

除了 sc create，另一个常被提到的方案是 Windows SDK 里自带的 srvany，早期很多人用它把 exe 包成服务。srvany 的问题在于功能太素：没有自动重启，程序退出后服务不会主动再拉起；没有日志重定向，所有输出照样丢失；配置存在注册表里，想改一个参数得手动打开注册表编辑器，找个键找半天，改错了服务直接起不来。

NSSM 在这些方面是碾压级的。我整理过一张对比表，基本能看出差距：

自动重启是 NSSM 最值钱的能力。程序异常退出后，默认行为就是等几秒重新拉起，不用在脚本里写 watchdog。日志重定向则是把服务进程的 stdout 和 stderr 分别指向文件，配合轮转参数，日志再也不会无限长下去。而这一切在 GUI 里都能改，装完服务后随时 nssm edit 打开配置界面，这比 sc create 删了重建、srvany 手改注册表舒服得多。

2.3 版本号 2.24-101-g897c7ad 意味着什么

这个版本号值得解释一下。“2.24”是上游的正式版本基线，“101”表示从 2.24 标签之后又合入了 101 个提交，“g897c7ad”是 Git 提交哈希的前缀，表示当前这个构建对应的准确代码状态。也就是说，它不是一个官方打的稳定版本号，而是 2.24 之后的一个持续构建产物，通常包含后续修复过的 bug 和一些小改进，整体行为与 2.24 基本一致，但在个别边界情况下更稳。

实际部署时，不必纠结于“开发构建不用于生产”的刻板印象。我的习惯是优先选用同期官方发布渠道里的最新构建，且在测试机上先把重启、日志轮转两条主链路验证通过再上线。要注意别拿 1.x 老版本的参数经验直接套到 2.24 上，比如 AppRotateOnline、AppKillProcessConsole 这些参数在老版本里没有，配置了反而会被忽略。

3. 把 Python 脚本注册成系统服务：安装、启动、验证三连

3.1 先写一个不自爆的脚本

不是所有脚本都适合直接注册成服务。脚本第一不能弹窗口，服务运行在 Session 0，GUI 根本显示不出来；第二不能依赖用户登录状态；第三要能一直跑下去，不能跑一次就自己退出。一个合格的常驻脚本长这样：

import os import time import datetime # 模拟一个轮询任务：每 5 秒写一条心跳日志 def main(): # 打印进程 PID，方便后面去 Task Manager / tasklist 里核对 print("service started, pid=", os.getpid(), flush=True) while True: now = datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") print(f"{now} heartbeat", flush=True) time.sleep(5) if __name__ == "__main__": main()

逻辑说明：while True 让进程保持常驻，这是服务化脚本的基本前提；每次循环打印带时间戳的心跳，NSSM 会把 stdout 重定向到日志文件，方便确认服务活着。flush=True 很关键，python 的 print 默认有缓冲，不强制 flush 的话日志会积在内存里，服务崩溃时最后几条记录就丢了，排查时少一堆线索。

参数说明：time.sleep(5) 控制心跳频率，实际项目里按业务需要改成几秒或几十秒都行；os.getpid() 只为了让服务端进程和任务管理器里的 PID 对得上，人多手杂时排查进程残留非常有用。

3.2 安装服务：命令行与 GUI 两种姿势

NSSM 安装服务的命令行写法很直接：

:: 进入 nssm.exe 所在目录（按实际路径修改） cd /d D:\tools\nssm :: 安装服务：服务名 my-task，程序 python.exe，参数是脚本路径 nssm install my-task C:\Python39\python.exe D:\scripts\run.py

逻辑说明：nssm install 的语法是“服务名 + 程序 + 参数”，参数会原样保存到服务配置里。上面这条命令等价于在 GUI 里把 Path 填成 python.exe、Arguments 填成脚本路径。服务名 my-task 是后续启动、停止、修改配置时都要用的唯一标识，建议起得有意义一点，比如按业务模块加前缀。

参数说明：程序路径建议写全路径，不要依赖 PATH 环境变量，因为服务启动时用的是系统环境，用户 PATH 不一定被加载。脚本路径如果带空格，用引号包住整体：nssm install my-task "C:\Python39\python.exe" "D:\my scripts\run.py"。

注册完之后，一般还要补两件事：日志重定向和重启延迟。命令行下用 nssm set 配置：

nssm set my-task AppStdout D:\logs\my-task.log nssm set my-task AppStderr D:\logs\my-task.log nssm set my-task AppRestartDelay 10000 nssm set my-task AppExit Default Restart

逻辑说明：AppStdout 和 AppStderr 把脚本输出和报错分别写进文件，这里指向同一个文件，方便整体看；AppRestartDelay 单位是毫秒，10000 表示进程异常退出后等 10 秒再拉起，避免程序反复崩溃时疯狂重启；AppExit Default Restart 显式声明“不管什么退出码都重启”，防止其他人误改成 Exit。

参数说明：如果希望“脚本正常退出也重启”，保持上面配置即可；如果希望脚本正常退出时服务真的停掉，把 AppExit Default 改成 Exit，异常崩溃时 NSSM 依然会拉起。这个按业务逻辑取舍，不能照搬。

另一种安装姿势是 GUI。在 cmd 里执行 nssm install my-task，直接弹出安装窗口，几个字段填一下就行：

• Path：python.exe 的完整路径，不要加引号
• Startup directory：脚本所在目录，脚本里有相对路径时必填
• Arguments：脚本路径和参数，带空格时用引号
• Service name：安装时定了，GUI 里是灰的
• Display name：显示在服务列表里的名字，比如“模拟项目X后台任务”

GUI 和命令行最终写进同一份配置，不存在两套结果，只是有些参数命令行写起来更快，有些参数（比如多行环境变量）GUI 更方便。

3.3 启动、查状态、杀进程验证自动重启

安装完先别急着收工，必须做一轮完整的启停验证。先走启动和状态检查：

# 启动服务 nssm start my-task # 查看服务状态 Get-Service -Name my-task | Select-Object Status, Name, StartType # 查看进程是否活着，按服务名过滤 tasklist /fi "services eq my-task"

逻辑说明：nssm start 是同步阻塞的，返回后服务应该处于 Running。tasklist 的 services 过滤器只显示绑定到该服务的进程，能直接确认 nssm.exe 和它拉起的 python.exe 是否都在。Get-Service 看到的是服务状态，不一定能看到子进程状态，所以两个命令要配合用。

参数说明：如果 tasklist 过滤出来只有 nssm.exe 没有 python.exe，说明脚本没起来，按第 4 章第一个坑的方向查；如果两个进程都在，就可以进入自动重启测试。

# 根据上一步查到的 PID，强制结束 python 进程，模拟脚本崩溃 taskkill /f /pid <上一步查到的PID> # 等 11 秒（AppRestartDelay 10 秒 + 启动缓冲） Start-Sleep -Seconds 11 # 再看进程有没有被重新拉起 tasklist /fi "services eq my-task"

逻辑说明：这一步是 NSSM 自动重启能力的核心验证。taskkill /f 强制杀掉 python.exe 后，注意 Get-Service 的状态不会变成 Stopped，因为真正的服务进程是 nssm.exe，它还在跑，只是子进程没了；等 AppRestartDelay 毫秒过去，NSSM 会重新拉起脚本。所以判断标准是 tasklist 里再次出现 python.exe，而不是看服务状态。这个误判我见过不止一次，有人发现“服务状态一直是 Running”就以为不用测重启，结果进程根本没被拉起来。

参数说明：测试完的恢复动作是 nssm stop my-task 再 nssm start my-task，把进程清干净，避免残留多个 python 实例互相抢资源。多实例场景下杀进程前一定要确认 PID 属于当前服务，别误杀别的服务。

4. 避坑指南：五条翻车记录与排查路径

4.1 服务启动即退出，事件日志一片空白

现象：nssm start 返回成功，但稍后 Get-Service 状态变成 Stopped，脚本没有任何输出，事件查看器里也找不到像样的报错，一片空白。

原因：脚本本身启动就报错了。NSSM 只是把进程拉起来，脚本一秒内崩溃退出，日志没来得及写或者被缓冲吞掉，自然什么都不留。另一个隐蔽原因是脚本放在 Session 0 环境下运行时，访问了网络盘、数据库等还没就绪的资源，启动阶段直接异常。

解决：先在 cmd 里手动跑一遍脚本，确认脚本本身能长期运行。确认脚本没问题后，把 AppStdout 配置到位，然后 nssm start，等几秒看日志文件有没有内容。如果日志文件是空的，再看退出码：nssm status my-task 会显示最后一次的退出码，结合 AppExit 配置判断 NSSM 是否有在拉。我一般会在脚本最开头加一个“打印启动完成”的日志，这样能区分“脚本没起来”和“脚本起来了但在初始化时挂掉”。

4.2 Path 带引号导致启动失败

现象：安装时把可执行文件路径写成 "C:\Python39\python.exe" 带引号，服务启动直接失败，nssm 报错或者 Windows 返回“服务没有响应控制功能”。

原因：GUI 里的 Path 字段和 Windows 的 binPath 不一样，NSSM 自己会处理路径解析，Path 不需要引号；引号如果出现在 Path 里，NSSM 反而会把引号当成路径的一部分去解析，结果程序真的找不到。

解决：记住一条规则——Path 只填裸路径，不带引号；路径里的空格由 NSSM 自己处理。参数要带引号时，放在 Arguments 字段里。命令行安装时同样逻辑：nssm install my-task C:\Python39\python.exe "D:\my scripts\run.py"，程序路径裸写，脚本路径按需带引号。这个坑特别邪门，因为 Windows 其他工具都习惯性要求路径加引号，到 NSSM 这里反过来，总有人被绕进去。

4.3 日志无限制增长，磁盘被写满

现象：服务跑了一个月后，日志文件从几百 MB 涨到几个 GB，服务器 C 盘直接被占满，其他程序跟着出问题。

原因：AppStdout 只做了重定向，没有开轮转。脚本里不加控制的 print 或异常堆栈持续输出，日志单文件无限增长。NSSM 的日志轮转不是默认开启的，必须显式配置 AppRotateFiles。

解决：在 nssm edit 的 I/O 选项卡里打开日志轮转，或者命令行设置：

nssm set my-task AppRotateFiles 1 nssm set my-task AppRotateBytes 10485760 nssm set my-task AppRotateOnline 1

逻辑说明：AppRotateFiles 开启后，NSSM 会在文件大小达到 AppRotateBytes 设定的字节数时切换到一个带时间戳的新文件，不中断服务。AppRotateOnline 是让重定向目标在滚动时保持在线，旧版本的坑是轮转时必须先停掉重定向，会有十几秒的日志丢失窗口；2.24 系列基本没这个问题。

参数说明：AppRotateBytes 推荐从 10MB 起步，生产环境里如果单条日志很大，可以放到 50MB。要按天轮转，再加 AppRotateSeconds 86400。注意 NSSM 的轮转是“切新文件”，不是“删除老文件”，历史日志要自己用计划任务清理，比如只保留最近 7 天的日志文件，删文件不会影响正在运行的服务。

4.4 服务停止后，子进程还赖着不走

现象：nssm stop my-task 后服务状态显示已停止，但 tasklist 里 python.exe 还在，端口还被占用，再次启动时报地址已被占用。

原因：脚本里起了子进程、线程池或者没处理停止信号，NSSM 停止服务时默认先尝试优雅关闭，等到超时后杀进程树；但有些 python 程序不响应控制台关闭事件，或者子进程脱离了进程树管理，导致 NSSM 认为已经停了，实际子进程成了孤儿进程。

解决：先设置停止行为参数，再优化脚本退出逻辑：

nssm set my-task AppKillProcessConsole 1 nssm set my-task AppStopMethodConsole 1000 nssm set my-task AppStopMethodWindow 1000 nssm set my-task AppStopMethodThreads 5000

逻辑说明：这几个参数表示停止服务时，NSSM 先发控制台事件等 1 秒，再向窗口发消息等 1 秒，最后等线程退出等 5 秒，超时后强制终止进程树。这是比较保守的配置。脚本侧更彻底的做法是监听退出信号，比如 python 里捕获 SIGINT/SIGTERM，在退出前把子线程 join 干净。

参数说明：生产环境里如果脚本里确实有不好杀的第三方子进程，调大 AppStopMethodThreads 的等待时间比直接加暴力参数靠谱，强制杀进程容易留下脏状态，下次重启服务时可能检测到上次残留而拒绝启动。

4.5 开机自启失败，手动启动却正常

现象：服务器重启后，服务状态是空的或者启动失败，但登录服务器手动 nssm start 一切正常，服务跑得很欢。

原因：服务启动时依赖的环境还没就绪。常见的有：脚本访问的数据库服务还没起来、依赖的网络共享盘还没挂载、脚本读的配置文件所在目录属于延迟加载的磁盘。Windows 服务默认的启动顺序又不保证你的服务在依赖对象之后跑，于是启动就是撞运气，时好时坏。

解决：把服务启动类型改成“自动延迟启动”，让服务在系统引导完成后 2 分钟左右再启动，给依赖服务和网络留出时间：

nssm set my-task Startup AutomaticDelayed

逻辑说明：AutomaticDelayed 是 Windows 服务管理器层面的延迟启动机制，比自己在脚本里写“先 sleep 30 秒再干活”优雅得多。延迟启动是在其他自动启动服务基本完成后才触发，适合对启动时序有依赖但不是强依赖的服务。

参数说明：如果脚本依赖的是某个具体服务，更可靠的方案是设置服务依赖。nssm set 本身不直接管这个，要在服务属性里配置依赖，或者在注册表 DependOnService 里手动加目标服务名。注意依赖服务名填的是服务内部名，不是显示名。

5. 日志轮转与多实例部署：把 NSSM 用到生产环境

5.1 日志轮转参数表与推荐组合

日志轮转是 NSSM 生产化绕不开的配置。我按实际经验整理过一组参数，这里直接列出来：

推荐组合是 AppRotateFiles=1、AppRotateBytes=10485760、AppRotateOnline=1，配合按天轮转的 AppRotateSeconds=86400。这个组合的好处是大文件有上限，单日日志也能独立成文件，排查问题的时候直接按日期定位，不用在几十 MB 的大文件里翻来翻去。

轮转产生的日志命名规则是“原文件名+时间戳”，比如 my-task.log 在切换后会变成 my-task.2025-06-01_14-30-22.log，新写入内容继续落到 my-task.log。这个命名规则在写日志采集脚本时可以直接利用，按前缀加时间戳去匹配。

有一点必须强调：NSSM 不做日志清理。轮转只是切文件，切下来的旧文件会一直留在磁盘上。我在一个项目里吃过亏，以为开了轮转就万事大吉，结果文件每天切一个，300 天下来照样吃了几 GB 空间。我的习惯是加一个计划任务，每天凌晨清理超过 N 天的日志文件，目录路径固定，清理脚本可以写成“按文件名时间戳过滤 + 删除”。

5.2 多实例部署：同一套脚本跑多个服务

很多时候同一套脚本代码要在同一台机器上跑多个实例，比如按端口拆分、按业务线拆分。NSSM 不需要为这种场景做任何特殊处理，装多个服务名就行：

:: 两个服务实例，同一脚本，不同端口参数 nssm install api-8001 C:\Python39\python.exe D:\deploy\api\run.py --port 8001 nssm install api-8002 C:\Python39\python.exe D:\deploy\api\run.py --port 8002

逻辑说明：每个服务名对应独立的 NSSM 配置，包括 Path、Arguments、日志路径，互不干扰。两个实例的日志文件要分开，否则多个进程写同一个文件会有写入竞争，日志内容互相穿插，排查问题时分不清哪行是哪来的。可以在配置时把 AppStdout 指向带端口号的路径：

nssm set api-8001 AppStdout D:\logs\api-8001.log nssm set api-8002 AppStdout D:\logs\api-8002.log

参数说明：服务名前缀加端口号是我比较推荐的做法，比 my-task-1、my-task-2 这种纯序号清晰得多，看到服务名就大概知道是哪个业务、哪个端口。服务名长度别超过 32 个字符，命令行的长度限制和注册表服务的命名规范都要注意。另外提醒一句：多实例时测试自动重启要格外小心，杀进程前务必看清 PID 属于哪个服务，tasklist /fi "services eq 服务名" 能直接套用，比从进程名猜靠谱得多。

5.3 环境变量注入：脚本配置外置

把配置写死在脚本里是服务化大忌。NSSM 支持给服务注入额外的环境变量，这样同一份脚本代码在不同实例里跑，读到的配置不同，不用改一行代码：

nssm set api-8001 AppEnvironmentExtra INSTANCE_ID=8001 nssm set api-8001 AppEnvironmentExtra APP_ENV=production

逻辑说明：AppEnvironmentExtra 里每个 KEY=VALUE 都会在服务启动时追加到系统环境变量里。脚本侧直接用 os.environ 读取：

import os instance_id = os.environ.get("INSTANCE_ID", "0") env = os.environ.get("APP_ENV", "dev") print(f"instance_id={instance_id}, env={env}", flush=True)

参数说明：环境变量注入比改配置文件好用的地方在于，服务重装或迁移时，所有配置跟着服务一起走，不用去记“改哪行配置”。多实例场景下尤其省事：脚本只读环境变量，不同实例注册时 set 不同的 INSTANCE_ID 就行，代码和配置彻底解耦。命令行方式设置多个环境变量时，注意 nssm set 的逻辑是覆盖式还是追加式，版本之间有些差异，最稳妥的方式是安装时一次性在 GUI 的 Environment 选项卡里把多行变量都填完，避免后来追加时把之前的覆盖掉。

6. 最后一点经验：nssm edit 与注册表导出让服务管理有后悔药

6.1 nssm edit：改参数不用删服务重装

NSSM 最让我省心的是配置可改。以前用 sc create 时代，改一个参数得先删服务再注册，动作大还容易出岔子；NSSM 里一条命令直接打开图形界面：

nssm edit my-task

改完点确定，服务会自动应用新配置。改 Path、Arguments、日志路径、环境变量这些都在 GUI 里完成。要注意的是，改完配置后服务不会自动重启，需要手动 nssm restart my-task 让新配置生效。这个操作模式用顺了之后，部署脚本的维护成本能低不少。

6.2 参数导出与批量部署：注册表克隆思路

NSSM 的服务配置最终存在注册表里，位置是 HKLM\SYSTEM\CurrentControlSet\Services\服务名\Parameters。这个特性意味着可以导出、迁移、批量部署：

:: 备份单个服务的完整配置 reg export "HKLM\SYSTEM\CurrentControlSet\Services\my-task" D:\backup\my-task.reg /y

逻辑说明：导出的 reg 文件里包含 NSSM 的 Parameters 键，以及 Windows 服务本身的不少配置项。拿到另一台机器上导入后，服务就能带着原参数克隆出来。批量部署的场景一般是：测试机上把服务调好，导出 reg，然后拿 reg import 到一批新服务器上。

参数说明：导入前检查四样东西，否则服务会启动失败——python 或 exe 路径在目标机器上存在、脚本路径存在、日志文件目录存在、服务名没有被占用。路径不一致时，打开 reg 文件全文替换路径文本再导入，这是最快的做法。另外提醒：不要跨机器直接导入到服务名不同的环境，注册表项里的服务名是主键，改名要谨慎处理。从那次批量部署翻车之后，我每次导入完都强制走一遍 nssm start、tasklist、杀进程验证这三步才安心。

希望这套经验能帮你把 NSSM 用得顺手，少走弯路。

本文还有配套的精品资源，点击获取