NSSM 2.10：任意 exe 注册 Windows 服务并自动重启

简介NSSM 2.10 是一款在 Windows 平台下将任意可执行文件便捷注册为系统服务的开源工具面向需要让程序开机自启、后台持续运行的开发与运维人员。该工具通过图形界面即可指定服务名称、启动参数、依赖项及运行账户并支持日志记录与异常处理尤其适合数据同步、监控脚本、自动化任务等常驻型应用。压缩包共 24 个文件内含 win32 与 win64 两个可直接运行的 nssm.exe、7 个头文件与 6 个 C 源码以及 README、ChangeLog、工程文件和图标资源便于学习服务封装原理并对照源码二次改造整个 zip 仅 158KB轻量便携。资源目前已有 223 人学习浏览既能作为 NSSM 的免安装发行包直接投入使用也是一份完整的源码级参考资料可帮助读者理解 Windows 服务与应用程序交互的核心机制。1. NSSM把任意 exe 变成 Windows 服务的免费方案先抛一个反直觉的结论Windows 自带的sc create也能把 exe 注册成服务但你得到的是一个“孤儿进程”——程序崩溃后系统不会自动拉起它标准输出和错误输出也没有落盘入口排查问题全靠猜。NSSMNon-Sucking Service Manager2.10 这个工具包解决的正是这件事它是一个服务包装器把你的 exe 作为子进程托管起来服务挂了自动重启输出日志按天切割退出码还能决定要不要拉起第三次。这个版本包里同时带了 win32 和 win64 两个目录的 nssm.exe拿到手解压就能用适合那些需要把后台同步工具、定时任务脚本、内网服务端程序变成“开机自启、无人值守”状态的场景。2. NSSM 是什么与为什么选它从服务机制到 2.10 包结构2.1 Windows 服务的运行机制决定了你不能直接跑 exeWindows 服务与普通进程最大的区别在于会话隔离服务由 SCMService Control Manager启动运行在 Session 0 里用户注销后它依然存在。普通 exe 即使手动丢进启动文件夹登录界面一出现就可能被杀掉更别说系统还没登录时就要拉起的场景。要绕过这个限制传统做法是自己写一个 .NET Windows 服务项目再用 InstallUtil 注册——但为了跑一个 Python 脚本去写 C# 服务工程代价明显过高。NSSM 的定位就是省掉这一步。它的核心工作方式是你告诉 NSSM“帮我跑哪个 exe、参数是什么”NSSM 自己注册为系统服务然后在服务启动时把目标 exe 拉起来作为子进程。注意一个关键点NSSM 不会把你的 exe 合并成服务而是把“管理 exe 生命周期”这件事做成了服务。这个设计带来两个直接好处一是目标程序完全不需要改造命令行能跑的程序都能被托管二是 NSSM 能够感知子进程退出并在配置的策略下决定是退出服务还是重新拉起子进程。2.2 对比 sc、winsw、任务计划程序为什么监控和日志是最短木板很多人问过“既然 sc create 能注册为什么还要 NSSM”。我用一个表格把几个常见方案的差异列一下方案崩溃自动重启日志重定向服务依赖配置图形界面sc create不自动需要额外 watchdog不支持有限支持无任务计划程序重启需要额外触发器配置不支持原生无有winsw支持较少参数需自行配 log 节点支持无NSSM 2.10支持可配置延迟和重启次数AppStdout/AppStderr 重定向支持 DependOnService有任务计划程序在“用户登录后触发”的场景下够用但如果是数据库服务、消息队列这类需要开机就在后台跑的进程任务计划程序会显得不稳定——它的触发条件基于事件而不是 SCM 的服务控制协议服务停止时系统不会主动通知它。winsw 是另一个开源选择配置走 XML适合喜欢把一切写进文件的场景但它的进程监控逻辑相对简单子进程被杀掉后恢复行为没有 NSSM 那么精细。NSSM 对“服务停了要不要拉起、ExitAction 怎么处理、重启延迟多少秒”都有独立参数这一点对长期运行的服务更加重要。2.3 2.10 压缩包内部结构先确认你要的是 win32 还是 win64拿到 nssm-2.10----Windows-service.zip 之后解压出来是一套源码加可执行文件的组合。常见文件清单如下文件/目录作用win32/nssm.exe32 位版本适合老旧程序或 32 位 Windowswin64/nssm.exe64 位版本Windows 10 x64 首选src/、.cpp、.h完整源码需要自己编译时用README.txt版本说明和基础用法ChangeLog.txt版本变更记录选择依据很简单Windows 10 基本都是 x64直接用 win64\nssm.exe 即可。需要注意一个小坑32 位 exe 可以被 64 位系统运行但 NSSM 的位数最好与你托管的程序一致。如果你托管的是 32 位旧程序NSSM 用 64 位版本通常也没问题因为 NSSM 只是启动子进程。我一般直接测试为主——先跑 64 位遇到加载异常再换 32 位。提示NSSM 不需要安装它在注册服务时会把自身路径写入服务配置。所以不要解压后乱动位置建议固定放在C:\tools\nssm\这类路径下再注册服务。3. 用 GUI 注册服务nssm install 的完整字段解读3.1 以管理员身份启动 GUI 注册服务NSSM 的图形界面在 2.10 版本里做得相当完整适合第一次接触服务托管的新手。打开管理员命令行win10 下按 WinX 选择 Windows PowerShell管理员切到解压目录执行cd C:\tools\nssm\win64 nssm install MyService执行后弹出图形窗口。这里有个细节如果当前命令行不是管理员权限NSSM 会直接报错或者在注册服务时失败。在 Windows 10 上UAC 弹窗确认之后nssm install第二个参数就是服务名这个服务名将来会出现在服务管理控制台services.msc里建议用英文不要带空格。界面核心字段是 Application 标签页下的几个输入框字段说明Application path要托管的可执行文件绝对路径Startup directory程序的工作目录必须显式填写否则部分程序无法找到相对路径的配置文件Arguments启动参数空格分隔带路径的参数要用引号Service name服务名称创建时不可修改很多人第一次在这界面翻车的原因是填了 Application path 但没填 Startup directory。NSSM 不会自动继承命令行当前目录如果你的 exe 依赖相对路径读配置文件就必须把 Startup directory 指到 exe 所在目录。填写完成后点击“Install service”按钮提示服务创建成功。3.2 在 GUI 中配置进程退出后的行为GUI 里的 Exit actions 和 Process 标签页值得单独说。Exit actions 就是定义“当被托管进程退出时NSSM 怎么办”的规则默认是 Exit 退出服务。但对于需要保持“服务永远在线”的进程需要改成 Restart然后在 Process 标签页设置 Restart delay重启延迟单位毫秒和 Restart throttle重启节流时间。这两个参数的效果是进程崩溃后 NSSM 等待设定的延迟再拉起避免进程还没释放完端口就被重新启动导致绑定失败。Process 标签页里还有一个 Pause/Continue 选项可以配置“当 NSSM 收到暂停服务指令时是否向子进程发送 Ctrl-Break 事件”。如果被托管程序是 Python 脚本或 Node 服务建议勾选“Send Ctrl-Break to the application”这样在命令行执行nssm stop MyService时子进程能收到信号做优雅退出而不是被 nssm 强杀。3.3 GUI 模式看不到日志配置去 I/O 标签页日志重定向界面的位置有点隐蔽需要在 I/O 标签页里配置。GUI 模式下你可以勾选“Redirect stdout to log file”和“Redirect stderr to log file”并分别指定日志文件路径。路径上注意不要用相对路径NSSM 在 GUI 模式下创建的日志路径是相对于当前进程启动目录的如果改过工作目录日志可能会落到意想不到的位置。GUI 模式的整体节奏是适合调试阶段先注册服务然后从服务控制台手动启动观察日志输出。但实际部署时我更推荐命令行方式因为配置可以写成脚本重装系统不至于再手动点一遍图形界面。4. 命令行注册与参数调优nssm set/edit 的完整参考4.1 用 nssm install 回车参数完成静默注册命令行方式比 GUI 更适合批量部署。注册命令如下nssm install MyService C:\app\my-server.exe --port8080 --configserver.ini nssm set MyService AppDirectory C:\app nssm set MyService DisplayName My Background Server nssm set MyService Description Handles scheduled tasks and TCP calls nssm set MyService Start SERVICE_AUTO_START关键点install命令接收的参数按顺序是服务名、exe 路径、启动参数。如果你想在服务名不变的情况下修改 exe 路径用nssm edit MyService打开 GUI 改 Application path但生产环境我更推荐用nssm set MyService Application C:\app\server.exe直接改这样变更记录留在脚本里。AppDirectory是多数人容易忽略的参数——即使命令行里配置了 exe 路径也必须设置工作目录否则运行时读不到相对路径的配置文件。参数Start SERVICE_AUTO_START的含义是把启动类型设为自动等价于服务控制台里的“自动延迟启动”下方的“自动”。如果要延迟启动可以换成SERVICE_AUTO_START配合nssm set MyService DelayedAutostart 1。4.2 核心参数表重启策略、退出码与日志旋转命令行方式能够设置 GUI 里不直接暴露的一些参数下面这张表是我实际用过并验证过的参数命令示例作用AppRestartDelaynssm set MyService AppRestartDelay 5000进程退出后延迟多少毫秒再重启AppExitnssm set MyService AppExit 3 Restart当退出码为 3 时执行 Restart 动作AppStdoutnssm set MyService AppStdout C:\logs\out.log重定向标准输出AppStderrnssm set MyService AppStderr C:\logs\err.log重定向错误输出AppRotateFilesnssm set MyService AppRotateFiles 1启用日志按大小/时间切割AppRotateBytesnssm set MyService AppRotateBytes 10485760日志超过 10MB 自动旋转DependOnServicenssm set MyService DependOnService mysql当前服务依赖 mysql 服务AppExit配置逻辑当进程退出码等于指定值时NSSM 执行 Restart/Exit/Throttle 动作。默认情况下任何退出码都会导致 NSSM 服务退出这恰恰是很多人配置 NSSM 后“服务启动就停止”的原因——你的程序可能因为缺少环境变量退出了NSSM 则“尽职尽责”地把服务状态标记为停止。这时候要看的是 AppStderr 日志而不是反复重启。AppRotateBytes的细节NSSM 检查日志文件大小是在子进程每次写 stdout/stderr 之后并非严格实时。如果把旋转阈值设得很小比如 1KB会频繁触发文件关闭和重命名影响性能。我一般在 5MB50MB 之间选值配合AppRotateOnline 1让旋转过程中不中断输出。4.3 服务操作命令start/stop/status 的几条实际用法注册完之后日常操作命令如下nssm start MyService nssm status MyService nssm stop MyService nssm restart MyService nssm remove MyService confirmnssm status输出一个数字状态码1 表示 SERVICE_STOPPED4 表示 SERVICE_RUNNING。脚本里做健康检查时可以用这个命令但要注意运行nssm start时如果服务已经在运行它会返回一个非零退出码但服务本身不受影响。remove后面加confirm是为了跳过交互式确认框在批量卸载场景下是必要的。如果你只删服务但保留日志文件直接 remove 即可NSSM 不会动日志目录。5. 日志重定向与应用托管Java、Python、Node 进程的落地配置5.1 把 stdout/stderr 同时接入滚动日志无登录用户运行程序的另一大痛点是“程序输出去了哪里”。手动启动时你能看到控制台打印但作为服务运行时没有终端。NSSM 的做法是把子进程的 stdout 与 stderr 重定向到文件。配置示例nssm set MyService AppStdout C:\logs\app-out.log nssm set MyService AppStderr C:\logs\app-err.log nssm set MyService AppRotateFiles 1 nssm set MyService AppRotateBytes 20971520 nssm set MyService AppRotateOnline 1这里AppStdout与AppStderr是两个独立文件。如果只配了 stdout程序异常堆栈打到 stderr 上就不会被记录排查问题时容易产生“没报错但程序死了”的错觉。AppRotateOnline的作用是 NSSM 在旋转日志文件时继续把新内容写入新文件而不是阻塞子进程。常见做法是设置默认的AppRotateBytes与AppRotateInterval单位秒双条件谁先触发谁旋转。注意日志目录必须提前创建NSSM 2.10 不会自动帮你在盘上建目录。如果C:\logs不存在服务启动后日志文件无法创建但 NSSM 不会报错直接在服务日志里记录一条异常信息。5.2 Java 应用托管路径带空格的完整写法Java 后端服务往往带有lib目录启动脚本是一长串java -cp参数。用 NSSM 托管 Java 服务时不要在 Application path 里填java.exe的路径就完事因为 classpath 中的相对路径会失效。正确配置是 Application 填 java.exe 绝对路径参数里用-jar或-cp指向绝对路径nssm install MyJavaService C:\Program Files\Java\jdk-17\bin\java.exe -Xms512m -Xmx1024m -jar C:\app\myapp.jar nssm set MyJavaService AppDirectory C:\app nssm set MyJavaService AppStdout C:\logs\java-out.log nssm set MyJavaService AppStderr C:\logs\java-err.log注意Arguments参数带空格时需要整体用引号包住并且传递给 NSSM 的是一个字符串所以命令行长度的转义规则要小心。Windows 命令行上会被解析为参数边界NSSM 内部会拼接成完整命令行。最稳的写法是把启动参数提前在本地试跑一遍确认在没有 NSSM 介入时命令行能直接拉起应用再加到 NSSM 配置里。如果 Java 进程不是通过java -jar启动而是.bat不要直接把 NSSM Application 指向.bat。.bat由 cmd.exe 解释执行而 NSSM 不会帮你启动 cmd。常见做法是改成cmd.exe /c C:\app\start.bat但这样退出码处理会变得复杂。更干净的方式是把.bat里的 java 命令提出来直接交给 NSSM。5.3 Python 与 Node虚拟环境和 npm 脚本怎么交给 NSSMPython 服务最常见的问题是激活虚拟环境手动跑时先activate但服务会话里没有这个动作。NSSM 配置里不要写python.exe或python3要写虚拟环境的绝对路径nssm set MyPythonService Application C:\app\venv\Scripts\python.exe nssm set MyPythonService AppParameters C:\app\server.py --worker2 nssm set MyPythonService AppDirectory C:\app nssm set MyPythonService AppExit Default Exit nssm set MyPythonService AppExit 1 Restart虚拟环境中的 python.exe 本质是个重定向入口它依赖同目录下的 activate 脚本和pyvenv.cfg所以AppDirectory建议设置为项目根目录不是 venv 目录这样server.py里读相对路径的模板文件不会出错。AppExit Default Exit表示如果退出码不是 1就让服务退出退出码为 1通常表示业务异常则执行 Restart。这种配置比“无论什么退出码都重启”更合理——如果 Python 脚本因为语法错误或配置缺失退出重启一万次都是白费。Node 服务同理Application 指向node.exe而不是 npm.cmd参数写你的入口 js 文件。npm 脚本启动的复杂场景我建议单独写一个不带守护逻辑的入口文件NSSM 只负责拉起 node不负责帮你 npm run。5.4 服务账户与权限LocalSystem 与指定账户的区别NSSM 默认服务账户是 LocalSystem这个账户在本地系统上权限极大能访问绝大多数目录但不能直接访问网络共享SMB 访问需要凭据。如果你的应用需要访问内网其他机器的数据库LocalSystem 可能因为凭据问题无法建立连接。此时需要给服务指定账户nssm set MyService ObjectName .\myuser mypassword.\myuser的写法表示本地用户如果是域账户写domain\user。设置之后NSSM 会更新服务配置注意服务账户密码过期后服务会启动失败。Windows 10 上如果发现服务在重启后自动停止检查事件查看器里的错误码如果是 Logon failure直接去服务控制台重新输入密码。我的习惯是给服务单独建一个“永远不会过期的本地账户”比如svc_myapp这样两年内不会再遇到凭据问题。6. 排查避坑NSSM 服务启动失败与退出码的五个现场6.1 服务启动后立即停止事件日志里只有“服务特定错误”现象注册完服务点“启动”一两秒后状态变回“已停止”事件查看器里只有服务控制管理器记录的服务特定错误没有具体退出原因。原因绝大多数时候是被托管程序因环境变量、缺失 DLL 或端口被占用直接退出。NSSM 默认 ExitAction 是退出服务于是 SCM 看到服务进程退出就标记为停止。这不是 NSSM 的问题而是目标程序没有正常起来。解决先看 NSSM 配置的 AppStderr 日志文件里面是程序自己的报错如果日志没生成尝试以 Interactive 方式先在普通命令行启动一遍同样的命令观察输出。我一般会在注册服务前先手动执行一遍目标命令确认它能稳定跑起来再交给 NSSM。6.2 日志文件有内容但服务还是不断重启现象AppStderr 日志里反复出现同一段报错比如数据库连接失败NSSM 按照 AppRestartDelay 不停重启日志持续增长服务永远处于 running 和 stopping 之间摇摆。原因AppExit Default Restart配置在生效但程序犯了非致命错误始终没有以非零退出码退出而是被 NSSM 反复拉起。解决给 AppExit 配一个更明确的退出码策略比如AppExit 3 Restart然后让程序在遇到无法恢复的数据库连接错误时exit(3)。这样不会无限重启。另一种做法是设置AppRestartDelay 30000加上AppThrottle 300000节流时间让重启频率降低给外部依赖恢复留出时间。6.3 GUI 里改了配置点了确定但服务行为没变化现象用nssm edit改完重启延迟保存成功nssm get MyService AppRestartDelay也返回了新值但服务崩溃后还是按旧延迟重启。原因NSSM 读取配置是启动服务时读取一次而不是每次重启子进程都重新读取。改配置后没有重启 NSSM 服务本身导致内存中的配置还是旧的。解决改完任何参数后都执行nssm restart MyService而不是nssm restart子进程。NSSM 服务的启动和停止是针对整个服务改为新配置必须让服务进入 stopped 状态后再启动。6.4 删除服务后注册表残留导致重装失败现象nssm remove MyService之后重新注册同名服务报“指定的服务已存在”但 services.msc 里看不到 MyService。原因NSSM 删除服务时不会删除注册表项HKLM\SYSTEM\CurrentControlSet\Services\MyService里的部分键值SCM 因为没有完全清理导致重名冲突。解决用sc delete MyService强制删除服务条目然后检查注册表是否有残留手动删除整个 MyService 键再重新注册。注意这个操作需要管理员权限而且要先确保服务处于停止状态否则删除过程会报错。6.5 Windows 10 上 NSSM 运行但服务不随开机启动现象注册为自动启动但系统重启后服务状态是 stopped不在自动启动的服务列表里。原因Windows 10 快速启动机制导致部分服务在启动阶段被跳过或者服务的 Start 参数是SERVICE_DEMAND_START没有真正改为自动。解决执行nssm set MyService Start SERVICE_AUTO_START然后去看服务控制台“启动类型”列是否为“自动”。如果已经是自动但仍不启动检查事件日志中是否有超时错误——服务启动时间超过 30 秒时SCM 会直接终止它。这种情况要把启动脚本里的耗时逻辑移到程序内部异步执行或者改成延迟启动。7. 进阶技巧多实例隔离、服务账户最小权限与卸载残留清理多实例部署是 NSSM 比较实用的进阶场景。同一个 exe需要同时跑两个实例监听不同端口时注册两个服务名比如myapp-8001与myapp-8002每个服务单独设置 AppDirectory 和参数即可。但要注意日志文件必须分开若两个服务共用同一个 stdout 日志文件NSSM 的文件锁机制会导致第二个服务启动时无法写入直接在 stderr 里报错。我一般会在服务名里带端口号同时日志路径也带服务名后缀。服务账户的最小权限配置也值得动手做一遍。默认 LocalSystem 虽然方便但安全风险不小。如果程序只需要读写某个目录和访问本机 TCP 端口可以用nssm set MyService ObjectName .\svc_user password指定一个普通用户然后给这个用户授予应用目录的读写权限。需要注意的是 AppDirectory 目录如果位于 Program Files 下普通用户可能没有写入权限导致程序启动时无法写临时文件。我的习惯是先创建C:\app\这样的自定义目录避免与 Program Files 的 ACL 冲突。停止与卸载是另一个容易被忽略的地方。nssm stop MyService是在向 NSSM 发停止指令NSSM 默认会通知子进程退出。如果子进程无法响应通知NSSM 会在超时后强制终止。要在卸载时彻底清理先保证子进程已经被杀掉再执行nssm remove MyService confirm最后手动删除日志目录。我见过有同事卸载后忘删日志一年后磁盘满了才发现是 NSSM 的旧日志在持续增长——虽然服务删了但日志文件还在。在多实例与权限这条链路上我踩过一次比较深的坑两个实例用了同一个配置文件的相对目录结果第二个实例启动时把第一个实例的配置覆盖了。从那以后我每次给服务分配参数时都强制把 AppDirectory 变量写进服务描述里并先在本地用同样的路径结构跑一遍命令再注册。如果你也准备部署多实例建议把每个服务的完整配置exe 路径、AppDirectory、AppStdout、AppStderr、AppExit、AppRestartDelay输出到一份文本里存成服务台账。这个习惯能让你在半年后重装系统时用一条循环命令把服务全部重建也让你在排查问题时不用打开六七个 GUI 窗口逐个看配置。NSSM 的真正价值不在于图形界面多好看而是让你能用几行脚本把一个服务的生命周期——启动、监控、日志、重启、删除——完整地管理起来希望这篇实战拆解能帮你在自己的 Windows 服务器上少走几步弯路。本文还有配套的精品资源点击获取