许可证文件没看明白，监控程序没开，后面的事全是盲人摸象

很多厂里的许可证服务器，装完能跑起来，就没人再动过了。工程师能打开 Creo 或者 NX，IT 就不管了。直到有一天厂商发函过来，或者许可证突然大面积不可用，才想起来去看服务器，结果连一个像样的日志都拿不出来。不是没日志，是当初装的时候没人勾那个选项，或者勾了但路径指向一个根本不存在的文件，debug log 一直是空的。许可证文件和监控程序这两样东西，是后面所有分析、优化、应对审计的地基。地基是虚的，上面盖什么都是白搭。

先说许可证文件，很多人压根没分清自己手里拿的是什么

FlexNet 系的许可证文件，.lic 或者 .dat，打开看 INCREMENT 行，有没有 HOSTID= 是第一个要命的分水岭。节点锁定（node-locked）的许可证，HOSTID 里嵌的是某台机器的 CPU ID 或者加密狗的 ID，软件只能在那台机器上跑。浮动（floating）的 INCREMENT 行里通常不出现指向客户端的 HOSTID，SERVER 行里的 hostid 标识的是许可证服务器本身，客户端通过 port@host 去借。这里最容易出的错是：拿着一份本质上是节点锁定的文件，硬按浮动的思路配环境变量，或者反过来，把浮动服务器的 SERVER 行 hostid 当成了绑定某台客户端的依据。结果就是一部分人能连上、一部分人死活连不上，错误码 -15 或者 -96 反复出现，但没人去翻文件本身，全在客户端那边折腾防火墙和 hostname。

还有一个很实际的坑：SERVER 行里的 this_host 忘了替换。很多模板文件里写的是 this_host，装的时候图省事没改，服务在 A 机器上跑着看起来没事，换一台机器或者主机名解析一变，直接起不来。gofarlic 的排查文档里专门提过这一点，主机名和许可证识别名对不上，服务就是起不来。这种事不复杂，但一旦发生，现场的人第一反应往往是重装，而不是去看 .lic 文件里那一行是不是还写着 this_host。

再说监控程序，不是“服务在跑”就等于“监控开着”

lmgrd 起来了，lmutil lmstat -a 能看到 feature 被签出，很多人就认为监控已经有了。那只是状态，不是历史。 lmstat 给你的是此刻谁占着什么，关掉窗口就没了。真正有用的是 debug log，也就是 lmgrd 用 -l 参数指定的那个文件，或者 lmtools 里 Config Services 勾了 Log File → Enabled 之后写入的那个 .log。这个文件记的是时间线上的签出、归还、拒绝、守护进程启停，有了它，你才能回答“Simulate 下午三点到底是谁在占着”“上周三的 -15 错误在服务端长什么样”这类问题。

最隐蔽的坑是 lmgrd 用错了账号在跑。Windows 上如果许可证服务是以某个域账号或者 Local System 启动的，日志文件所在目录那个账号不一定有写权限。服务显示 “Server Start Successful”，lmstat 也正常，但 debug log 就是零字节。等到出事了想查，发现日志从来没写过东西。Linux 上反过来，用 root 跑 lmgrd 不是不行，但很多厂商建议用非特权用户起，权限和路径一错，日志同样写不进去。“服务活着”和“日志在写”是两件事，装完必须去目标路径看一眼文件大小和时间戳，别信状态灯。

手工先把地基夯实，顺序别跳

第一步，把 .lic 文件当代码审一遍。 打开文件，确认 SERVER 行的主机名或 IP 跟实际服务器一致，不是 this_host。确认你依赖的每个 INCREMENT 行有没有 HOSTID，对应的是客户端锁定还是服务器绑定。确认 VENDOR 行指向的 daemon 名称和端口跟实际跑的进程对得上。这一步不需要任何工具，用文本编辑器就能做，但能拦住后面一大半的“莫名其妙连不上”。

第二步，把 debug log 真正打开，并且验证它在写。 Windows 下用 lmtools，Config Services 里 Path to the debug log file 指向一个你确定服务账号有写权限的路径，勾上 Use Services 和 Start Server at Power Up，Save Service，然后 Stop 再 Start。Linux 下起 lmgrd 的时候别省那个 -l 参数：./lmgrd -c /path/license.lic -l /path/lmgrd.log，路径用绝对路径，别用相对路径给自己挖坑。起来之后，tail -f 盯着日志，在客户端开一次软件，看日志里有没有对应的签出记录。没有记录就等于没开，回去查权限和路径。

第三步，用 lmutil lmstat 做日常巡检，但别把它当日志用。 lmutil lmstat -a -c port@host 适合快速确认服务活着、feature 数量对不对、当前占用概况。想按 feature 过滤，加 -f 参数。但这个命令的输出是瞬时的，排查趋势和审计取证还得靠 debug log 的文本。把 lmstat 当成体温计，把 debug log 当成病历本，别拿体温计当病历用。

工具是给“手工拧不动”的那部分准备的

手工能做的到此为止：文件看明白了，日志在写了，lmstat 会用了。再往下走，会遇到两个手工解不了的问题。一个是进程级活性判断：lmgrd 只知道证被签出，不知道客户端进程是不是在真的算，一个大装配重建可以把证占两个小时，鼠标键盘一动不动，但进程在吃 CPU；反过来，有人开着 Creo 去开会，证挂着但进程空闲。debug log 能告诉你签出时长，但告诉不了你“这段时间里软件在不在干活”。另一个是按模块、按部门的细粒度调度，OPTIONS 文件能做组预留，但规则一多，手工维护的成本和出错概率就上来了。

GOFARLIC（LicOMS）这类工具切的就是这两块。它把许可服务器的签出信号和客户端的进程状态叠在一起看，回收前先判断进程是不是真在跑计算，走“提醒—确认—释放”的节奏，而不是一刀切踢人。调度层面支持按模块设阈值和优先级，把 Simulate、Advanced Assembly 这类高价低频的 feature 从基础建模的并发争抢里隔出来。这些东西 lmgrd 本身不提供，lmstat 也不提供，手工脚本能做到一部分，但规模上去之后维护成本不划算。

一个小例子，问题就出在“文件”和“日志”上

某做模具设计的厂，六十来号 Creo 用户，许可证服务器跑在一台老 Windows Server 上。症状是每个月总有那么一两次，整个办公室突然大面积报 -15，重启许可证服务就好，但过一阵又犯。IT 一直在查网络和防火墙，换过交换机，重装过客户端，没用。后来把 .lic 文件打开，SERVER 行里主机名是一个两年前已经下线的旧机器名，现在靠 DNS 里一条没人记得的 CNAME 记录勉强解析着，偶尔解析失败，客户端就连不上。同时查 lmtools 里的 debug log 路径，指向 D:\lic\log.dat，但 D 盘在那台服务器上根本不存在，服务账号往一个不存在的路径写日志，写一次失败一次，日志文件从来没生成过，所以之前每次出问题都只能靠猜。把 SERVER 行改成当前主机名、在本地磁盘建了日志目录、重新 Save Service 并 Start 之后，debug log 开始正常写入。下一次 -15 再冒出来的时候，日志里直接显示是某个网段的客户端在特定时间点集中发起请求导致 lmgrd 响应超时，问题定位从“重启试试”变成了有据可查。许可证一个没加，采购一分没花，但后面再也没因为 -15 盲目重装过。