“修理不好用的WebSphere,有时候要看运气.”这个是我接触过很过有历史的运维工程师经常说的一个梗;研发人员也经常说这个程序在我这里运行好好的,怎么到你那就不灵了?问题是你的,你自己解决.
声明一下:这篇日志不是说明什么责任、扯皮问题,而是运维体系中的一种标准和规范.
这不最近部门内接手了一个移交的运维项目,里面涉及到各种IBM配套产品,使用的操作系统平台是Windows Server 2008 R2.
而IBM的产品通常情况下都会配套Java开发,这使得建立在操作系统之上是IBM一套自有的产品平台,IBM仅仅是使用了Windows的这个平台帮他管理硬件和用户交互而已,所以出现的问题通过查阅产品日志一般都能解决,但是总感觉的有点乱是不?毕竟这一套产品如果没有安装部署文档,需要费些心思先把这个环境了解清楚,而且很多时候是在帮助他人解决相关问题,你完全没有时间去了解这个环境当时是怎么搭建起来的,问题的解决过程或许就是这样变得没有头绪了.
而对于部署人员为了达到高效快速,多会使用绿色版的产品部署,这就会带来一个现象,IBM的很多产品都是可以通过命令行独立运行(复制即可用),此时服务器中会搞好多个cmd的黑框停在服务器上,再有一些可能连日志打印都直接输出到这个黑框里,导致黑框消失日志不知道去哪取.
但是常规情况下IBM安装产品通常会将启动过程变成一个服务,这个好处就是任何问题都可在事件查看器中得到追溯.
而今天遇到的问题恰巧和WebSphere有关,运维人员说怎么启动都起不起来,相应的问题是cmd黑框下启动不了日志也无法输出,不过这个机器下面有当时安装遗留下来的一个WebSphere的服务,接手后我尝试了通过服务启动,发现可以短暂启动后有自动停止运行.
![clip_image001[7]](http://images0.cnblogs.com/blog/481786/201505/171643438836784.png "clip_image001[7]")
Figure 1通过了解事件,定位时间,找到了这条错误信息
Could not determine the process id of the java process. Changing the IBMWAS70Service - WIN-RKALU0SGIQUNode01 service status to the "stopped" state. To prevent this error, try recreating this service with the -logRoot parameter. The value of the logRoot parameter should be the directory in which the server's .pid file is created.
这个看起来像是无法创建进程文件pid而抛出来的问题,解决办法是使用-logRoot参数查看这个pid文件到底需要被放置在哪里?不过小弟才疏学浅,对WebSphere了解不多,思前想后了一下还是请来Sysinternals的帮忙,用自己熟悉的工具解决问题会比较妥当,而这个软件开发者有一款对Windows进程进行实时监控的产品Procmon.
打开Procmon开始监控之后,再次运行启动服务,通过历史回溯按钮Ctrl+t,发现了挂在services进程下面的was服务,点开可以看到图标样式不实诚,说明该进程已经在我当前时间点前结束掉了.
![clip_image002[4]](http://images0.cnblogs.com/blog/481786/201505/171643451644743.png "clip_image002[4]")
Figure 2通过查看lifetime,进程名,启动命令行信息确定我们需要找的进程,然后点下IncludeSubtree对这个进程下所有的子进程一起过滤出来
再进一步过滤结果为PATH NOT FOUND的反馈,找到了进程消失的原因.
![clip_image003[4]](http://images0.cnblogs.com/blog/481786/201505/171643471172074.png "clip_image003[4]")
Figure 3这个pid进程原来是要创建在这个”D:Program FilesIBMWebSphereAppServerprofilesAppSrv01logsserver1”目录下面,而返回值是路径不可得.
好了,现在知道问题了,就去看看这个路径是否存在,进过检查发现WebSphere的概要下面没有这个AppSrv01这个文件夹,那就不可能有其下的logs文件夹了,手工创建一下这两个文件夹,然后再继续找错误,还记得Figure 2图示上面的子进程两个呢,一个cmd,一个java他们都最终变成了灰色.
![clip_image004[4]](http://images0.cnblogs.com/blog/481786/201505/171643493676960.png "clip_image004[4]")
Figure 4变灰的cmd进程历史遗迹有对AppSrv01logs目录的请求,现在已经建立了,应该不会有问题了,我们在接的看java进程的
![clip_image005[4]](http://images0.cnblogs.com/blog/481786/201505/171643506641690.png "clip_image005[4]")
Figure 5Java进程很有意思,他居然需要访问这个AppSrv01概要下的bin目录,并且里面还有配置脚本
这个配置脚本在哪里可以获取到?继续在WebSphere的概要文件夹下寻找线索,发现有一个AppSrv02in文件夹下面有我们所需要的脚本文件,处于方便,看看有无副作用,就把Appsrv02下面的bin全部复制到了Appsrv01下面,再起启动,was服务正常了!
真是谢天谢地,不好玩的WebSphere是怎么就这么难启动的呢?想一下这个AppSrv01就莫名其妙的消失了?是不是和部署的时候默认概要冲突?原来的开发环境使用的是AppSrv02而移植到这里一个全新安装的环境下新的默认概要是01,为了部署新的概要02就把01重命名成了02,但是安装服务还是用01来操作的.就现在的表现来看,有些问题可能存在人工介入实现快速部署但有不能彻底铲除原有遗留信息导致的种种怪异问题.
![clip_image006[4]](http://images0.cnblogs.com/blog/481786/201505/171643518055606.png "clip_image006[4]")
Figure 6可以看到系统内已经没有原先的90809060这两个初始化自带概要AppSrv01的业务和管理端口了
当人违背了机器的执行条件的时候就会给运维带来诸多不便,那么对于这个机器上面跑了好多黑框,需要手工启动was服务的问题我们可以通过将其转变成系统服务来处理,这样有了Windows事件作为统一问题寻找点,规范了运维流程,解放双手.
对于这个例子IBM也深知WAS已服务启动的话需要人为配置诸多参数等很多人为因素导致的错误,为了规范was手工启动变服务,IBM提供了而外的配置工具,没有跟先有发布版本一同流出,需要的运维同学可以在这里获取到: http://www-01.ibm.com/support/docview.wss?uid=swg21397335 ,支持WebSphere6.0~8.5的所有发行版.
![clip_image007[4]](http://images0.cnblogs.com/blog/481786/201505/171643527117048.png "clip_image007[4]")
Figure 7通过使用WASServiceCmd 工具快速安全的设置was服务启动项,最下面禁用的那个是原来随系统安装进来的默认概要
-=EOB=-