许可服务器天天报警吵死了，把那些“僵尸”踢掉就安静了

定的周六凌晨1点的闹钟起来重启许可服务，现在刚操作完，泡的红烧牛肉面还冒着热气。

说实话这活儿我干过不下几十回了，但每次闹钟响的那一下心里还是紧一下，毕竟许可服务这东西牵一发动全身，全公司二百多号人的授权全捏在这一个服务上。我提前三天就在日历上标了今天这个窗口，因为看日志只有周六凌晨这个点绝对没人用。为了保证万无一失，周五白天我做了三次全量备份，第一次备份到本地D盘，第二次拷到移动硬盘，第三次上传到云盘，三份备份分三个地方存，生怕哪个环节出问题。半夜1点闹钟准时响，我从床上爬起来的时候手都是凉的，打开电脑第一件事就是确认lmstat输出是空的，当前没有一个人在线上，确认完毕才敢停服务。停了服务之后等了大概十秒钟确认进程完全退出，才开始动手。但即使准备做得这么足，操作过程中还是冒了两身冷汗。

趁着重启的窗口，我把最近两个月一直想调但没敢动的几个优化一起做了。第一件就是把那堆"僵尸告警"的阈值重新设了一下。之前告警设得太敏感了，可用许可数低于5个就触发，但研发高峰期三五个人同时点开软件卡在队列里是常有的事，根本算不上故障。结果就是我的手机每天平均收到二十多条告警，大部分点开一看其实没大事，时间长了连真告警都被我当成假的了。这次我把阈值改成了"可用数低于2个且持续超过十分钟"才触发，同时把推送时段做了分级，工作日上午8到12点推微信，其他时段只推邮件不弹通知。插曲是改告警配置文件的时候我手快把另一个服务的监控规则给覆盖了，点保存之后才反应过来，赶紧从备份里把原文件拷回来重新改了一遍。要是没发现这个失误，明天一早上班那套监控服务全得乱套，几十个假告警能把大家手机震没电。

第二件是把那几个"死活回收不掉的顽固会话"做了专项清理。我们的回收脚本正常运行了快一年了，但日志里总有那么几个Feature的会话偶尔会卡住，超时到了但回收指令执行失败，报错说"session not found"，但lmstat里明明还挂着。我查了一圈发现是FlexNet的版本bug，某些老Feature在特定情况下会话状态会变成zombie，标准的lmremove命令拿它没办法。解决办法是用操作系统级别的工具直接杀掉那个进程占用的端口，然后再重启服务清理残留状态。这次重启的时候我提前把几个已知的僵尸Feature记录下来，停服务之后顺手把对应的临时端口缓存文件全删了，重新拉起服务之后那些顽固会话不会再出现了。插曲是删缓存文件的时候我差一点把当前版本的有效授权文件给一起删了，因为两个文件在同一个目录底下文件名特别像，一个叫license.dat一个叫license.old，我光标停在那个old文件上头愣了两秒才确认没搞错。

第三件是把日志转储的频率从每天一次改成了每六小时一次。之前每天切一次日志，单文件太大，每次切的时候磁盘IO抖得厉害，直接导致那几分钟的服务响应变慢。而且一旦服务突然崩了，当天的日志还没来得及切出来就丢了，排查原因的时候少了一大截数据。改成六小时一次之后，每份日志文件小了很多，IO抖动也轻了，关键是就算崩了最多损失六个小时的数据，不像之前一天的数据全没了。插曲是改完转储配置重启日志服务的时候，我忘了把旧日志文件挪走，结果新进程起来之后发现目标目录下还有同名文件没归档，直接报错退出了，害得我重新启动了一次才正常跑起来。

最后说两个许可服务重启绝对不能省略的前置检查项。第一个是重启之前必须用lmutil做一次授权文件的完整性校验，确认license.dat没有损坏、没有过期、FEATURE行语法正确，不然你服务停了再发现文件是坏的，哭都哭不出来。第二个是用lmstat确认当前在线会话数为零之后，再等两分钟，别心急，因为有时候会话虽然显示为0但后台还有残留的socket连接没释放干净，等两分钟让系统自己清掉再停服务，能省掉后续一大堆端口冲突的问题。

面有点坨了但汤还挺浓的，赶紧吃完睡觉。亲测好使，这周已经帮3个同事解决了同款问题。