windows 服务使用心路历程

 Windows 服务使用心路历程

       产品进程生命周期管理，需要作为Windows服务守护进程。进程管理是ruby Win32/Service 接口写的，但后来在运行过程当中出现了由于权限导致的机器蓝屏，后来进程管理的作者觉得是ruby 的Win32/Service 接口导致的，要把这块换成C++的的，于是找了个NSSM的开源工具，于是这就噩梦的开始。。。

       由于产品进程里有不同停止方式，比如Jetty 、Nginx 等等，不能接收NSSM默认的强杀策略，NSSM也缺乏与子进程的通讯接口，没有给进程发 stop signal，实际上Windows的进程也不支持这种通信方式，问题来了，是放弃NSSM还是修改它的实现，我到网上找了下似乎没有更好的选择，虽然鄙人不懂C++，还是选择跟NSSM死磕了，方案是在NSSM 停止的时候给子进程发送了Ctrl+c 事件，然而在子进程监听Ctrl+c 事件，子进程去控制整个进程树，然后问题有出现了，进程树当中有些进程对Ctrl+C事件也有监听，这样进程就不受根进程控制了，也不满足需求了，然后否决了发送Ctrl+C来通信，进程通信第一想到应该是管道，所以决定从这里下手，由于鄙人对C++不懂，捣鼓了半天也没搞定，后来请熟悉C++的人帮忙也没搞定，后来他说通过注册表来通信，这个方案虽然不是正道，但也好使，虽然这样做，给整个程序带来了很多麻烦，但修修补补也还凑合用着。

       后来进程树加了RabbitMQ，由于RabbitMQ 需要Administrator 权限，否则有些功能不能正常使用，解决方案是给Windows 服务用Administrator账户登录，但需要用程序的方式给它加进去，问题又出现了，首先我给的方案是用 Dos 命令 Sc 提供的接口来做，好像不稳定，原因待会说，而且提供的是Dos交互方式，看起来很程序员，这个时候又想起来爱恨交加的C++，不就是简单的输入密码界面和简单win32 api 调用嘛，做了一个基于Window forms的程序，但发现需要依赖.net Framework, 目标机器是不一样有的，马上换成MFC的，也很快做好了，结果发现了一个很诡异的问题，花了我一天半时间，就是用 ChangeServiceConfig API 方式更新登录账号，然后启动服务，报了一个账号不能登录 1069的错误，然后手动设置账号就可以了，然后再通过运行那个程序也可以了，后来发现是 administrator 账户默认没有服务登录权限，这我认为是Windows 的bug，可以通过控制面板->管理工具->本地安全策略->本地策略->用户权限分配->作为服务登录 将administrator 加进去就OK了(Windows 2008 )，通过Sc接口来设置不稳定也是这个问题，MSDN上提供程序的方式给administrator 账户加服务登录权限，可以参考 http://support.microsoft.com/kb/132958/zh-cn ，问题总算解决了。

      其实饶了一个弯，花了很多时间去研究NSSM，但实际上要解决的问题就是进程树由于权限问题运行不稳定的问题，给服务加登录账户就可以了，真是选择错，步步错。