nssm 服务封装与守护：Windows 常驻程序自启、重启、日志轮转

1. nssm 是什么，为什么 Windows 上需要它

把某个程序做成 Windows 服务，这件事看起来简单，真动手的时候经常一地鸡毛。尤其是业务程序本身只是一个 exe、一个 jar、一段 Python 脚本或者一个 Node 入口文件，它压根不是按 Windows 服务规范写的。你如果直接双击运行，窗口一关程序就停；放到任务计划程序里，又很难做到崩溃自动拉起、日志集中管理、开机稳定自启。nssm 这个工具，就是解决这个问题的老牌选手。它的全称是 Non-Sucking Service Manager，直译过来有点糙，但意思很明确：把普通程序封装成 Windows 服务，并且负责守护它。关键词里的 nssm、windows、服务封装、守护工具，基本就是它的全部核心能力。

我最早用 nssm 是给一个 Java 后台程序做 Windows 服务封装。那台机器是 Windows Server，客户要求开机自启、进程掉了自动重启、日志要写到固定目录，还不能弹出黑窗口。用 sc 命令注册服务不行，因为 Java 进程根本不响应服务控制管理器的指令；用任务计划程序能开机启动，但进程崩溃后无法可靠重启，日志也散落各处。后来换成 nssm，配置完 AppDirectory、AppStdout、AppStderr、AppExit 之后，机器重启、进程异常退出、日志轮转这些事都省心了。从那以后，只要是 Windows 环境下的常驻程序，我基本都会先考虑 nssm。

它适合谁？如果你手头有 Java jar 包、Python 常驻脚本、Node 服务、Go 编译出来的 exe、Elasticsearch 这种需要后台常驻的中间件，或者公司内部的小工具需要开机自动运行，nssm 都能派上用场。它不要求你改代码，不要求你引入额外的服务框架，也不要求你懂 Windows 服务编程。你只需要告诉它：启动哪个程序、参数是什么、工作目录在哪、日志写到哪里、崩溃后怎么办。剩下的交给它。对于运维、后端开发、桌面软件支持、测试环境搭建，甚至个人电脑上的自动化任务，它都是一个非常务实的工具。

1.1 从“脚本窗口不能关”到“无人值守服务”

很多人第一次接触服务封装，是因为一个非常朴素的需求：程序必须一直在后台跑，而且不能被人误关。比如你写了一个定时抓取数据的 Python 脚本，或者一个对内提供接口的 Java 小服务。命令行里运行没问题，但每次都要手动开窗口，关掉窗口程序就结束，服务器重启后还要人工登录再启动。这个模式在开发机上凑合，在服务器上就是事故隐患。

Windows 服务的好处是它由服务控制管理器统一管理，可以设置自动启动、延迟启动、失败恢复、依赖关系，还可以在不登录桌面的情况下运行。问题在于，普通程序不会说“服务语言”。服务控制管理器启动一个服务时，会要求这个服务在 30 秒内报告启动状态，还要响应停止、暂停、继续等控制码。一个普通的 Python 脚本或 Java 进程根本不懂这些，硬注册成服务后，要么启动超时，要么停止服务时进程杀不掉。nssm 在中间做了一层适配：它自己作为服务入口，负责跟 Windows 服务控制管理器对话，然后把真正的业务程序作为子进程拉起来，监控它的生命周期。

这个设计带来的直接好处是，你不需要改一行业务代码。程序原来怎么运行，现在还是怎么运行。nssm 负责“翻译”和“守护”。你可以把它理解成一个尽职的包工头：Windows 只认它，它去管理底下干活的工人。工人累了、倒了、不干了，它负责重新叫起来； Windows 说要停工，它负责通知工人收尾，收不了再强制结束。对业务程序来说，它只是被另一个进程启动而已。

1.2 nssm 与 sc、srvany、任务计划程序的取舍

Windows 自带的 sc 命令可以创建服务，但它要求可执行文件本身实现服务入口。很多老程序不满足，所以早年间大家用 srvany.exe，也就是 Windows Resource Kit 里的工具。srvany 也能把普通程序包装成服务，但它的配置要改注册表，日志、重启、轮转、停止方法这些都不够直观。nssm 相当于 srvany 的现代替代品，提供命令行和图形界面两种配置方式，参数更细，日志重定向和崩溃重启是原生能力。

任务计划程序也能实现开机启动，甚至能设置“如果任务失败，按以下频率重新启动”。但任务计划程序更偏向“定时触发”，在服务守护这件事上有几个短板：它依赖任务计划服务，交互式运行和后台运行的边界容易混淆；程序崩溃后的重启策略不够细；停止任务时不一定能优雅通知子进程；日志管理也要自己想办法。对于“必须常驻、必须稳定、必须无人值守”的程序，Windows 服务仍然是最正统的形态，nssm 则是把普通程序送进这个形态的捷径。

还有一个选择是 WinSW，它和 nssm 定位类似，配置用 XML，对 Java 服务支持也不错。两者没有绝对好坏：nssm 命令行更顺手，GUI 编辑方便；WinSW 的 XML 配置适合纳入版本管理。我的习惯是，临时排障、快速封装用 nssm；如果是长期维护、配置需要进 Git 的项目，会把 nssm dump 出来的配置也一起备份。工具是死的，关键看你能不能把启动路径、工作目录、日志、重启策略这四件事说清楚。

1.3 适用边界：哪些程序适合封装，哪些不适合

nssm 不是万能的。它擅长管理“前台常驻型”进程，也就是那种启动后一直运行、通过控制台输出日志、收到终止信号能退出的程序。Java 的java -jar、Python 的常驻脚本、Node 的node server.js、Go 编译的 exe、以及 Elasticsearch 这类中间件，都很适合。反过来说，如果一个程序本身已经是 Windows 服务，比如 Docker Desktop 安装后注册的服务、SQL Server 的服务，就不要再套一层 nssm，否则会出现双重服务管理，停止逻辑容易打架。

另外，短时任务、定时任务不适合用 nssm 常驻。nssm 的守护逻辑是“进程退出后按策略重启”，如果一个脚本设计成跑完就退出，nssm 会不断把它拉起来，形成反复启动。跑完就结束的任务应该用任务计划程序，或者让脚本内部循环。还有那种必须依赖桌面会话、必须弹出界面、必须跟用户交互的程序，也不适合做成服务。Windows 服务运行在 Session 0，和桌面隔离，强行让服务显示界面是历史遗留做法，现在既不安全也不稳定。

一个很实用的判断标准：这个程序能不能在命令行里用start /b或者后台方式稳定运行？如果能，并且它不需要桌面交互，那 nssm 大概率能接。如果它在命令行里都必须盯着窗口、手动点按钮，那先别急着封装，先把程序改造成适合后台运行的模式。

2. nssm 守护机制拆解：它到底怎么让程序变成服务

很多人会用 nssm，但说不清它内部到底做了什么。结果一旦遇到“服务启动成功但程序没起来”“停止服务后进程还在”“日志文件不写”这类问题，就只能靠猜。理解 nssm 的工作模型，排查问题时能少走很多弯路。简单说，nssm.exe 自己被注册成 Windows 服务，服务控制管理器启动的是 nssm，而不是你的业务程序。nssm 启动后，再根据配置创建子进程，把业务程序拉起来。之后它持续监控子进程状态，并根据退出码和配置决定是否重启、如何记录日志、如何响应停止指令。

这个模型里有两个关键角色：Windows 服务控制管理器，简称 SCM；以及 nssm 自己。SCM 只跟 nssm 对话，不直接管你的程序。你的程序在 SCM 眼里不存在。这也解释了为什么 nssm 的服务名和业务程序名可以完全不同。服务名只是 SCM 里的标识，业务程序路径是 nssm 的配置项。理解这一点，后面所有配置都会变得顺理成章。

2.1 Windows 服务控制管理器与 nssm 的角色分工

Windows 服务控制管理器负责维护服务数据库，处理启动、停止、暂停、继续等控制请求，还负责在系统启动时按启动类型拉起服务。它启动一个服务时，会调用服务入口点，并等待服务报告状态。普通程序没有报告状态的逻辑，所以直接注册会失败。nssm 实现了完整的服务入口，它会及时向 SCM 报告 SERVICE_RUNNING，让服务状态变成“正在运行”。与此同时，它在后台创建子进程运行真正的业务程序。

这个分工带来一个很重要的现象：nssm 服务显示“正在运行”，不代表你的业务程序一定健康。SCM 只看到 nssm 在运行，nssm 只保证子进程被拉起来了。如果业务程序启动后立刻崩溃，nssm 会按 AppExit 策略处理，可能是重启，也可能是停止服务。所以排查时要分清是“nssm 层”的问题，还是“业务程序层”的问题。前者看 Windows 事件查看器里的服务控制管理器日志，后者看 nssm 重定向出来的 stdout 和 stderr。

还有一个细节：nssm 作为服务运行时，它的当前工作目录默认可能是C:\Windows\System32，而不是业务程序所在目录。这就是为什么命令行里能跑、服务里跑不起来。命令行运行时，你的当前目录是程序目录，相对路径都能找到；服务运行时，当前目录变了，配置文件、证书、模板、数据库文件全都找不到。解决办法就是设置 AppDirectory，让 nssm 在启动子进程前把工作目录切过去。这个参数看似不起眼，实际是 nssm 配置里最重要的几个参数之一。

2.2 子进程监控与崩溃拉起逻辑

nssm 启动子进程后，会等待它退出。子进程退出时，nssm 能拿到退出码。根据 AppExit 配置，它可以决定对某个退出码执行什么动作：重启、忽略、退出、或者执行其他动作。默认情况下，很多配置会对非零退出码执行重启。你可以针对不同退出码设置不同策略，比如退出码 0 表示正常结束，不重启；退出码 1 表示异常，延迟 5 秒重启。这个能力对于业务程序来说非常实用，因为有些程序会用特定退出码表示“需要重新初始化”。

AppRestartDelay 控制重启前的等待时间，单位是毫秒。这个参数很关键。如果程序因为端口被占用、配置文件错误、数据库连不上而瞬间崩溃，而你把重启延迟设成 0，nssm 会疯狂拉起进程，日志瞬间刷爆，CPU 也会被拖高。更合理的做法是设置一个几秒的延迟，让系统喘口气，也避免日志被无意义地灌满。AppThrottle 则控制启动节流，防止服务在短时间内反复启动。对于启动成本高的程序，比如 Elasticsearch，延迟可以设大一点，比如 10 秒到 30 秒。

需要注意，nssm 的“守护”是进程级守护，不是业务级健康检查。它只能看到子进程还在不在，不能判断接口是否返回 200、数据库连接池是否耗尽、消息队列是否堆积。如果你的程序进程活着但业务已经假死，nssm 不会主动重启。这种场景需要额外的健康检查脚本，比如定时请求本地健康接口，失败后调用nssm restart 服务名，或者直接结束进程让 nssm 拉起。不要把 nssm 当监控系统用，它是服务封装工具，不是 APM。

2.3 标准输出、错误输出与日志轮转机制

nssm 可以把子进程的 stdout 和 stderr 重定向到指定文件。配置项是 AppStdout 和 AppStderr。这对常驻程序非常有用，因为很多程序默认把日志打到控制台，做成服务后控制台没了，日志也就丢了。重定向到文件后，至少能追溯启动失败、异常堆栈和运行输出。我的习惯是 stdout 和 stderr 分开写，排障时先看 stderr，因为错误堆栈通常在那里。

但日志不能只写不管。nssm 提供了轮转参数：AppRotateFiles、AppRotateOnline、AppRotateBytes、AppRotateSeconds。AppRotateFiles 设为 1 表示启用轮转；AppRotateOnline 设为 1 表示服务运行期间也可以轮转；AppRotateBytes 按字节数切割，比如 10485760 表示 10MB；AppRotateSeconds 按时间切割，比如 86400 表示一天。注意，轮转逻辑是 nssm 在写日志时触发的，不是外部 logrotate。它会重命名当前日志，然后继续写新文件。对于已经自己管理日志的程序，比如 Java 用 Logback 按天切割，就不需要再让 nssm 轮转，否则容易出现两套轮转打架。

还有一个常见坑：程序输出有缓冲。Python 默认会缓冲 stdout，导致日志文件半天不更新，看起来像卡死。解决方法是启动 Python 时加-u参数，或者设置环境变量PYTHONUNBUFFERED=1。Java 程序如果通过 System.out 输出，通常也会有缓冲，最好使用日志框架直接写文件，而不是依赖控制台重定向。Node 程序一般输出比较及时，但也要注意某些日志库的异步刷盘策略。日志为空不一定是 nssm 没干活，很可能是程序把输出憋在缓冲区里。

2.4 服务账户、权限与工作目录的隐形坑

Windows 服务以某个账户身份运行。默认可能是 LocalSystem，这个账户权限很高，能访问本地大多数资源，但在网络共享、域资源、映射驱动器上会有身份问题。LocalSystem 访问网络共享时是以计算机账户身份出去的，很多文件服务器不认。NetworkService 权限更低，适合不需要高权限的服务。最稳妥的做法是为业务程序创建一个专用本地用户或域用户，只授予必要的目录权限，然后让 nssm 用这个账户运行服务。

配置账户的命令是nssm set 服务名 ObjectName。如果是本地账户，可以写.\username加密码；如果是域账户，写DOMAIN\username。需要确保该账户有“作为服务登录”的权限，否则服务启动会报权限错误。还要注意工作目录和日志目录的权限。如果服务账户对 AppDirectory 没有读取权限，程序启动就会失败；对日志目录没有写入权限，日志就是空的。很多“命令行能跑、服务不能跑”的问题，本质都是账户和权限差异。

工作目录还有一个容易忽略的点：AppDirectory 不仅影响相对路径，还影响程序加载动态库、读取配置文件、写入临时文件的行为。比如某个程序默认在当前目录下创建logs、data、temp目录，你设置错了 AppDirectory，它就会跑到C:\Windows\System32下面去创建，轻则找不到文件，重则因为权限不足直接崩溃。所以配置 nssm 时，我一定会检查 AppDirectory 是否指向程序根目录，并且用服务账户实际测试读写权限。

3. 从零开始的 nssm 安装与命令行速查

nssm 的安装非常简单，它本身是一个绿色工具，下载后解压就能用。官方提供 32 位和 64 位版本，现在绝大多数 Windows 服务器和桌面系统都是 64 位，选择 64 位版本即可。下载来源建议使用官方渠道，避免从不明站点获取被篡改的 exe。解压后你会看到nssm.exe，把它放到一个固定目录，比如C:\Tools\nssm\，然后把这个目录加入系统 PATH，后续在任意命令行窗口都能直接调用 nssm。

这一章我把常用命令和配置入口整理出来，方便你直接抄作业。需要说明的是，nssm 的图形界面和命令行配置的是同一套参数。你可以先用命令行快速安装，再用nssm edit 服务名打开图形界面微调。图形界面适合不熟悉参数的人，命令行适合脚本化和批量部署。

3.1 下载、解压与 PATH 配置

把 nssm 放到固定目录后，右键“此电脑”进入属性，打开高级系统设置，进入环境变量，在系统变量的 Path 里追加C:\Tools\nssm\。保存后重新打开命令行，执行nssm version，能看到版本号就说明配置成功。如果不想改 PATH，也可以在命令行里用绝对路径调用，比如C:\Tools\nssm\nssm.exe install 服务名。但在写部署脚本时，建议统一使用绝对路径，避免因为 PATH 环境差异导致脚本在服务器上找不到命令。

提示：nssm 是服务封装工具，不是系统自带组件。每台目标机器都需要放置 nssm.exe，并且注册服务时使用的路径要指向这台机器上的实际位置。把开发机配置直接复制到服务器时，路径差异是常见故障点。

3.2 常用命令清单与 GUI 编辑入口

下面这张表是我平时最常用的命令，基本覆盖了服务封装的全生命周期。你可以把它当成速查表保存。

图形界面里最常改的标签页是 Application、Details、Log on、I/O、Exit actions、File rotation。Application 里填程序路径、启动目录、启动参数；I/O 里填 stdout 和 stderr；Exit actions 里设置退出后的动作；File rotation 里设置日志轮转。命令行和 GUI 没有本质区别，只是入口不同。

3.3 服务安装、启动、停止、删除的最小闭环

一个最小可用的封装流程通常是这样：先把程序在命令行里跑通，确认命令、参数、工作目录、环境变量都正确；然后用 nssm 安装服务；接着设置 AppDirectory、AppStdout、AppStderr；再设置启动类型为自动；最后启动服务并观察日志。这个顺序很重要，不要一上来就注册服务，否则出了问题你分不清是程序本身跑不起来，还是服务封装配置错了。

# 1. 安装服务并指定程序 nssm install MyApp "C:\Program Files\Java\jdk-17\bin\java.exe" -jar "D:\apps\myapp\myapp.jar" # 2. 设置工作目录 nssm set MyApp AppDirectory "D:\apps\myapp" # 3. 设置日志输出 nssm set MyApp AppStdout "D:\apps\myapp\logs\stdout.log" nssm set MyApp AppStderr "D:\apps\myapp\logs\stderr.log" # 4. 设置自动启动 nssm set MyApp Start SERVICE_AUTO_START # 5. 设置崩溃后延迟重启 nssm set MyApp AppExit Default Restart nssm set MyApp AppRestartDelay 5000 # 6. 启动服务 nssm start MyApp

删除服务时，如果服务正在运行，先停止再删除。nssm remove MyApp confirm里的 confirm 是为了防止误删。删除后服务列表里就不再显示。如果只是想临时停用，可以把启动类型改成SERVICE_DEMAND_START，也就是手动启动，而不是直接删除。这样下次需要时还能快速恢复。

4. 三类实战封装：Java 服务、Python 脚本、Elasticsearch

光讲命令不够，实际封装时每种程序的坑都不一样。这一章我挑三个最典型的场景：Java jar 服务、Python 常驻脚本、Elasticsearch 中间件。它们分别代表了 JVM 生态、脚本生态和中间件生态，配置思路有共通之处，也有各自需要注意的细节。你把这三种吃透，其他程序基本可以照葫芦画瓢。

4.1 封装 Java jar 为 Windows 服务

Java 程序是最常见的封装对象。假设你有一个myapp.jar，平时用java -jar myapp.jar --spring.profiles.active=prod启动。封装成服务时，Application 填 Java 可执行文件路径，AppParameters 填-jar "D:\apps\myapp\myapp.jar" --spring.profiles.active=prod，AppDirectory 填D:\apps\myapp，这样程序读取同目录下的config、logs、templates时就不会找错地方。

Java 服务要特别注意 JAVA_HOME 和内存参数。如果服务账户的环境变量里没有 JAVA_HOME，某些程序启动时会报找不到 Java。稳妥做法是在 nssm 里设置 AppEnvironmentExtra，把 JAVA_HOME 和 PATH 显式传进去。内存参数不要写死在命令行里，优先使用 jar 内部的 JVM 参数文件，或者通过JAVA_OPTS环境变量注入。这样调整堆大小时不用改服务配置。

nssm install MyJavaApp "C:\Program Files\Java\jdk-17\bin\java.exe" -jar "D:\apps\myapp\myapp.jar" --spring.profiles.active=prod nssm set MyJavaApp AppDirectory "D:\apps\myapp" nssm set MyJavaApp AppEnvironmentExtra JAVA_HOME="C:\Program Files\Java\jdk-17" nssm set MyJavaApp AppEnvironmentExtra JAVA_OPTS="-Xms512m -Xmx2048m" nssm set MyJavaApp AppStdout "D:\apps\myapp\logs\stdout.log" nssm set MyJavaApp AppStderr "D:\apps\myapp\logs\stderr.log"

注意：如果 Java 程序自己用 Logback 或 Log4j 写文件日志，AppStdout 可能只包含少量控制台输出。不要因为 stdout 文件很小就以为日志没写，先去程序配置的日志目录看看。反过来，如果程序把大量日志打到控制台，nssm 重定向文件会增长很快，必须配置轮转。

4.2 封装 Python 脚本常驻运行

Python 脚本封装成服务的坑主要集中在解释器路径、虚拟环境、输出缓冲和工作目录。假设你用虚拟环境D:\apps\worker\venv，启动命令是D:\apps\worker\venv\Scripts\python.exe D:\apps\worker\main.py。nssm 的 Application 要填虚拟环境里的 python.exe，而不是系统全局的 python。否则依赖包可能找不到。

AppDirectory 设为D:\apps\worker，这样脚本里的相对路径才正确。环境变量方面，建议设置PYTHONUNBUFFERED=1，让输出实时写入日志文件。如果脚本依赖PYTHONPATH或者自定义环境变量，也通过 AppEnvironmentExtra 注入。启动参数可以用-u强制不缓冲，但环境变量方式更干净。

nssm install PyWorker "D:\apps\worker\venv\Scripts\python.exe" "D:\apps\worker\main.py" nssm set PyWorker AppDirectory "D:\apps\worker" nssm set PyWorker AppEnvironmentExtra PYTHONUNBUFFERED=1 nssm set PyWorker AppStdout "D:\apps\worker\logs\worker.out.log" nssm set PyWorker AppStderr "D:\apps\worker\logs\worker.err.log" nssm set PyWorker AppExit Default Restart nssm set PyWorker AppRestartDelay 5000

Python 脚本还要注意异常处理。如果脚本因为未捕获异常退出，nssm 会按策略重启。但如果异常发生在启动阶段，比如数据库连不上，就会形成“启动、崩溃、重启、再崩溃”的循环。我的做法是在脚本入口加一层日志和退出码控制：可恢复错误等待重试，不可恢复错误写明确日志并退出，让 nssm 的延迟重启起作用。不要把重启当万能药，频繁重启会掩盖真正的配置问题。

4.3 封装 Elasticsearch 实现开机自启

Elasticsearch 在 Windows 上可以作为一种服务运行。很多人搜索 windows 启动 elasticsearch，找到的方案就是 nssm 或官方服务脚本。用 nssm 封装 ES 时，Application 指向elasticsearch.bat，AppDirectory 指向 ES 安装根目录，这一点非常关键。因为 ES 启动时要读取config/elasticsearch.yml、jvm.options、data和logs目录，工作目录错了直接起不来。

ES 对内存和文件句柄有要求，服务账户权限也要够。不要用 LocalSystem 跑生产 ES，建议创建专用账户，给 ES 安装目录和数据目录授予读写权限。JVM 堆大小在config/jvm.options里设置，nssm 不需要重复传内存参数。启动参数如果需要指定-Epath.data或-Epath.logs，可以写在 AppParameters 里。服务启动类型设为自动，并考虑设置延迟启动，避免机器刚开机时磁盘和网络还没就绪，ES 抢资源导致启动失败。

nssm install Elasticsearch "D:\elasticsearch\bin\elasticsearch.bat" nssm set Elasticsearch AppDirectory "D:\elasticsearch" nssm set Elasticsearch AppStdout "D:\elasticsearch\logs\nssm-stdout.log" nssm set Elasticsearch AppStderr "D:\elasticsearch\logs\nssm-stderr.log" nssm set Elasticsearch Start SERVICE_AUTO_START nssm set Elasticsearch AppRestartDelay 15000 nssm set Elasticsearch AppThrottle 5000

提示：ES 自己的日志在logs目录下按天生成，nssm 重定向的 stdout/stderr 是补充信息。不要把两者混在一起看。如果 ES 启动失败，先看 ES 自己的日志，再看 nssm 的 stderr，最后看 Windows 事件查看器里的服务错误。

4.4 封装 Docker 相关辅助进程的注意点

Windows 上安装 Docker 后，Docker Desktop 会注册自己的服务，通常不需要你用 nssm 再去包装 dockerd。强行包装容易和 Docker Desktop 的服务管理逻辑冲突。更常见的做法是：用 nssm 封装一个“等待 Docker 就绪后启动容器”的辅助脚本。比如机器重启后，Docker 服务启动需要时间，业务容器依赖 Docker，这时可以写一个 PowerShell 或 Python 脚本，循环检查 Docker 引擎是否可用，可用后再执行docker compose up -d，然后把这个脚本用 nssm 封装成服务，并设置依赖 Docker 服务。

这种场景下，AppDirectory 要指向脚本所在目录，AppParameters 最好写绝对路径。脚本内部要有超时和重试，避免无限等待。nssm 的 DependOnService 可以配置依赖，但 Windows 服务依赖只保证启动顺序，不保证依赖服务已经“业务就绪”。所以脚本里的健康检查不能省。Docker 相关服务通常需要较高权限，账户选择要谨慎，能用专用账户就不要用 LocalSystem。

5. 高级配置：日志切割、重启策略、依赖关系与多实例

基础封装只能让程序跑起来，真正决定长期稳定性的，是日志、重启、依赖和多实例这些高级配置。nssm 的参数很多，但常用的就那么十几个。这一章我把最值得花时间调的几组参数拆开讲，顺便说说背后的取舍。你不需要一次全用上，但遇到对应场景时要知道去哪里找。

5.1 AppExit 与 AppRestartDelay 的重启策略

AppExit 决定子进程退出后 nssm 怎么做。默认动作可以设为 Restart、Ignore、Exit、Suicide 等。Restart 表示重新启动子进程；Ignore 表示不管，服务继续运行但不重启子进程；Exit 表示 nssm 自己也退出，服务停止；Suicide 表示 nssm 结束自己并让服务停止。实际配置时，通常会把 Default 设为 Restart，然后针对退出码 0 设为 Ignore 或 Exit，表示正常结束不重启。

AppRestartDelay 是重启延迟，单位毫秒。它非常关键。延迟太短，程序崩溃后会瞬间重启，日志疯狂增长，CPU 被反复初始化拖高。延迟太长，故障恢复时间变长。我的经验是：普通业务程序设 3000 到 5000 毫秒；启动慢的中间件设 10000 到 30000 毫秒；如果程序因为端口占用崩溃，延迟再长也没用，必须解决端口冲突。AppThrottle 控制启动节流，防止服务在短时间内反复启动。它和 AppRestartDelay 配合使用，能避免“崩溃风暴”。

nssm set MyApp AppExit Default Restart nssm set MyApp AppExit 0 Exit nssm set MyApp AppRestartDelay 5000 nssm set MyApp AppThrottle 3000

上面配置的意思是：默认退出码都重启；退出码 0 表示正常结束，nssm 也退出；重启前等 5 秒；启动节流 3 秒。这样既能自动恢复异常，又不会在程序正常退出时反复拉起。

5.2 日志轮转参数和避免磁盘写满

日志写满磁盘是 Windows 服务运维的经典事故。nssm 的日志轮转能解决一部分问题，但前提是配置正确。AppRotateFiles 设为 1 启用轮转；AppRotateOnline 设为 1 允许服务运行时轮转；AppRotateBytes 按大小切割；AppRotateSeconds 按时间切割。两个条件可以同时存在，谁先满足就触发谁。

nssm set MyApp AppRotateFiles 1 nssm set MyApp AppRotateOnline 1 nssm set MyApp AppRotateBytes 10485760 nssm set MyApp AppRotateSeconds 86400

这组配置表示：日志文件运行中也可以轮转，达到 10MB 或超过一天就切割。注意，nssm 的轮转不是删除旧日志，而是重命名当前文件并创建新文件。旧日志会一直留在目录里，所以还需要配合外部清理策略，比如任务计划程序定期删除 7 天前的日志。如果你的程序自己已经按天切割日志，建议关闭 nssm 轮转，避免双重切割。判断标准很简单：程序日志目录里已经有按日期命名的文件，就不需要 nssm 再管。

注意：日志目录必须存在，并且服务账户有写权限。nssm 不会主动创建不存在的目录。如果 AppStdout 指向一个不存在的文件夹，日志重定向可能失败，服务本身却照常运行，结果排障时什么也看不到。

5.3 服务依赖与启动顺序

Windows 服务支持依赖关系。nssm 可以通过 DependOnService 设置依赖。比如你的业务服务依赖 SQL Server，可以设置依赖MSSQLSERVER；如果依赖 Docker 服务，可以设置对应的服务名。依赖关系的作用是：依赖的服务先启动，当前服务才会启动。但它不保证依赖服务已经准备好接受连接。SQL Server 服务显示“正在运行”时，数据库可能还在恢复中；Docker 服务启动后，引擎可能还需要几秒才可用。

所以依赖关系要和程序内部的连接重试配合。我的做法是：数据库连接池配置重试，启动时不要因为第一次连接失败就退出；如果程序启动阶段强制要求数据库可用，就用一个包装脚本先探测端口，再启动主程序。nssm 的 DependOnService 只是第一道保险，不是万能钥匙。

nssm set MyApp DependOnService MSSQLSERVER

设置依赖后，可以通过sc qc MyApp或nssm dump MyApp查看依赖是否生效。删除依赖时，用nssm reset MyApp DependOnService恢复默认。注意依赖的服务名必须是 Windows 服务名，不是显示名称。比如 SQL Server 的显示名称可能是SQL Server (MSSQLSERVER)，服务名才是MSSQLSERVER。

5.4 多实例部署与端口冲突规避

同一台机器上跑多个相同程序时，nssm 的多实例能力就派上用场了。服务名必须唯一，比如MyApp-8001、MyApp-8002。每个实例使用独立的程序目录、配置文件和日志目录，避免相互覆盖。端口、数据目录、锁文件、临时目录都要区分开。最忌讳的是两个实例共用同一个数据库文件或同一个日志文件，轻则日志混乱，重则文件锁冲突导致服务崩溃。

我的多实例部署模板是：为每个实例复制一份程序目录，修改配置文件里的端口和数据路径，然后分别用 nssm 安装服务。服务账户可以相同，但目录权限要分别授予。日志文件名带上实例名，比如stdout-8001.log。如果程序支持通过命令行参数覆盖端口，优先用参数，而不是改配置文件，这样配置更直观。

nssm install MyApp-8001 "C:\Java\bin\java.exe" -jar "D:\apps\myapp-8001\app.jar" --server.port=8001 nssm set MyApp-8001 AppDirectory "D:\apps\myapp-8001" nssm set MyApp-8001 AppStdout "D:\apps\myapp-8001\logs\stdout.log" nssm install MyApp-8002 "C:\Java\bin\java.exe" -jar "D:\apps\myapp-8002\app.jar" --server.port=8002 nssm set MyApp-8002 AppDirectory "D:\apps\myapp-8002" nssm set MyApp-8002 AppStdout "D:\apps\myapp-8002\logs\stdout.log"

多实例场景下，停止和重启要逐个操作。nssm restart MyApp-*这种通配符不一定被支持，最好写循环脚本。批量操作时加错误处理，避免一个实例失败导致整个脚本中断。

6. 常见故障与排查清单

nssm 用久了，你会发现大部分故障都集中在几个点上：路径、权限、工作目录、日志、停止方法。这一章我把踩过的坑整理成排查清单，遇到问题按顺序过一遍，基本能定位到原因。不要一上来就重装服务，先看日志和事件查看器，信息通常已经告诉你了。

6.1 服务安装成功但启动失败

服务安装成功只代表注册表里有了记录，不代表程序能跑。启动失败时，先看 Windows 事件查看器里的“Windows 日志 -> 系统”，筛选来源为“服务控制管理器”的错误。常见错误是“服务没有及时响应启动或控制请求”，错误码 1053。这个错误通常意味着 nssm 启动子进程失败，或者子进程启动后 nssm 无法正确报告状态。优先检查 Application 路径是否存在、参数是否正确、服务账户是否有执行权限。

另一个常见错误是“拒绝访问”。这通常是服务账户权限不足，或者程序路径位于服务账户无权访问的目录。比如你把程序放在某个用户的桌面目录下，服务账户是 LocalSystem，可能因为网络驱动器映射和用户配置文件差异找不到路径。解决办法是把程序放到公共目录，比如D:\apps，并给服务账户授予读取和执行权限。

提示：排查启动失败时，临时把服务账户改成 LocalSystem 测试一下。如果 LocalSystem 能启动，说明是权限问题；如果还是不行，说明是路径、参数或程序本身问题。测试完记得改回专用账户。

6.2 程序在命令行能跑，nssm 里跑不起来

这是最经典的坑，九成原因是工作目录和账户环境不同。命令行运行时，当前目录是你的程序目录，环境变量是你登录用户的；服务运行时，当前目录可能是 System32，环境变量是服务账户的。相对路径找不到文件、PATH 里缺少运行时、用户级环境变量缺失，都会导致启动失败。

解决步骤：第一，设置 AppDirectory 为程序根目录；第二，用 AppEnvironmentExtra 显式注入必要的环境变量，比如 JAVA_HOME、PATH、自定义变量；第三，检查程序读取的配置文件路径，尽量改为绝对路径；第四，用服务账户登录一次，手动在命令行里运行相同命令，确认权限和环境是否一致。这四步做完，大部分“命令行能跑、服务不能跑”的问题都会消失。

6.3 日志文件为空或乱码

日志为空先检查三件事：AppStdout 和 AppStderr 是否配置、目录是否存在、服务账户是否有写权限。如果都正常，再看程序是否真的往 stdout 写日志。有些程序只写自己的文件日志，不往控制台输出，nssm 自然抓不到。还有些程序输出被缓冲，导致日志延迟写入。Python 加-u或PYTHONUNBUFFERED=1可以解决缓冲问题。

乱码问题通常是编码不一致。Windows 命令行默认代码页可能是 GBK，程序输出 UTF-8，或者反过来。nssm 重定向的是字节流，不做编码转换。解决办法是统一程序输出编码为 UTF-8，并用支持 UTF-8 的编辑器查看日志。如果程序输出中文乱码，可以在启动参数或环境变量里强制编码，比如 Java 加-Dfile.encoding=UTF-8。

6.4 服务无法停止或残留进程

停止服务时，nssm 会尝试用多种方法结束子进程。默认顺序包括发送控制台 Ctrl-C、发送窗口关闭消息、终止线程、终止进程。如果程序不响应前几种，nssm 最终会强制终止。但如果程序启动了子进程或子线程，强制终止可能只杀掉父进程，留下残留进程。结果就是服务显示已停止，端口还被占用。

解决办法是配置 AppStopMethodSkip 和 AppStopMethodConsole 等参数，调整停止方法的顺序和跳过项。更根本的办法是让程序自己处理停止信号，优雅关闭。比如 Java 程序注册 shutdown hook，Python 程序捕获 SIGTERM 或 KeyboardInterrupt，Node 程序监听 SIGINT。程序能优雅退出，nssm 就不需要强杀，残留进程也会少很多。

# 查看当前停止方法配置 nssm dump MyApp # 跳过控制台方法，直接尝试窗口关闭和终止 nssm set MyApp AppStopMethodSkip 1

注意：强制终止是最后手段，可能导致数据损坏。数据库类程序、写文件的程序，一定要先尝试优雅停止。设置停止超时，给程序留出收尾时间。

6.5 常见问题速查表

这张表不是万能答案，但能帮你快速缩小范围。实际排障时，顺序很重要：先看服务状态，再看事件查看器，再看 nssm 日志，最后看程序自身日志。层层递进，不要跳步。

7. 运维经验与安全建议

nssm 能把程序封装成服务，但服务长期稳定运行，靠的是配置之外的习惯。比如用最小权限账户、定期备份配置、升级前先演练停机、监控服务状态。这些东西文档里不一定写，但生产环境里非常值钱。我把自己在 Windows 服务运维上的一些经验整理出来，希望能帮你少踩几个坑。

7.1 最小权限原则与账户选择

能用专用账户就不要用 LocalSystem。LocalSystem 权限太高，一旦程序被利用，攻击者就能拿到系统级权限。专用账户只授予必要的目录读写权限，能显著降低风险。创建本地用户后，用secpol.msc或services.msc授予“作为服务登录”权限，然后通过 nssm 的 ObjectName 配置账户和密码。如果程序需要访问网络共享，优先使用域账户，并确保共享权限和 NTFS 权限都正确。

程序目录权限建议设置为：专用账户读取和执行，日志目录修改和写入，数据目录修改和写入。不要给整个磁盘完全控制权限。配置文件里如果包含密码、密钥，要限制读取权限。Windows 安全日志里可以记录服务账户登录事件，定期审计异常登录有助于发现配置错误或滥用。

7.2 升级 nssm 和业务程序的安全停机流程

升级业务程序时，不要直接覆盖正在运行的程序文件。Windows 会锁定正在执行的 exe 和 jar，覆盖可能失败，或者导致服务运行异常。正确流程是：先nssm stop 服务名，确认进程完全退出；备份旧版本和配置文件；替换程序文件；nssm start 服务名；观察日志和端口；确认业务正常后再清理旧备份。如果服务启动失败，快速回滚旧版本，不要在现场反复试错。

升级 nssm 本身也要谨慎。nssm 是服务入口，如果替换了 nssm.exe，已经注册的服务路径指向的是旧文件。你需要确认服务配置里的 Application 是否指向 nssm.exe 所在路径。如果升级后路径变了，服务会启动失败。稳妥做法是保持 nssm 安装路径不变，只替换文件内容，并在测试环境先验证。

7.3 监控与告警的补充

nssm 只保证进程存活，不保证业务健康。生产环境至少要补充三层监控：第一层是 Windows 服务状态，监控服务是否处于运行状态；第二层是端口和进程，监控程序是否在监听预期端口；第三层是业务接口，监控核心功能是否返回正常。可以用 PowerShell 脚本定期检查，也可以用现成的监控 Agent。发现异常时，先尝试nssm restart，如果反复重启失败，再告警人工介入。

日志监控也很重要。nssm 重定向的 stderr 里如果出现大量异常堆栈，说明程序在不断报错。可以写一个简单的脚本，定时扫描 stderr 文件中最近几分钟的错误关键字，触发告警。不要等到磁盘写满或服务崩溃才发现问题。对于 Elasticsearch 这类中间件，还要监控集群健康状态和磁盘水位。

7.4 我踩过的几个坑

第一个坑是 AppDirectory 没设，程序在C:\Windows\System32下找配置文件，启动直接失败。后来我养成习惯，安装服务后第一件事就是nssm dump确认 AppDirectory 和 Application 是否正确。第二个坑是日志目录不存在，nssm 不报错，服务照常运行，但日志为空，排障时两眼一抹黑。现在我会在部署脚本里先创建日志目录并授权，再安装服务。

第三个坑是 Python 输出缓冲，日志文件半小时不更新，误以为程序卡死，重启了好几次。后来统一加-u和PYTHONUNBUFFERED=1。第四个坑是服务账户没有“作为服务登录”权限，启动报拒绝访问，查了半天才发现是账户策略问题。第五个坑是停止服务时 Java 进程没收到优雅关闭信号，导致数据文件损坏。后来给所有 Java 服务加了 shutdown hook，并调整了 nssm 的停止方法。这些坑看起来琐碎，但每一个都值得写进部署检查清单。

最后再分享一个小技巧：配置完成后执行nssm dump 服务名 > service-config.txt，把当前服务的完整配置导出保存。换机器部署时，对照这份配置逐项设置，比凭记忆靠谱得多。如果服务很多，可以写一个 PowerShell 脚本批量导出，纳入版本管理。下次再遇到“服务怎么又起不来”的问题，先翻出这份配置，对照 Application、AppDirectory、ObjectName、AppStdout 这几个关键项，通常一眼就能看出问题。