通信端口(progID)被占用时的快速处理步骤

发布时间:  2015-04-24 浏览次数:  107 下载次数:  0
问题描述
当升级、修改或者重启某些服务时,常常会遇到服务无法重启成功的情况,查看日志报TcpInitFailed-errorCode=111。有时把所有服务都停用了,把icdcomm也停了,再次重启平台仍有类似的错误。
处理过程
无论如何,progId被占用,则一定有某个进程在后台占用了此progId,我们只需要借助一些方法和工具准确定位到问题进程即可。首先我们要确定产生该问题的原因是否是端口已经被占用,我们可以通过icdcommView这一工具来快速定位。

1. 在Windows下该工具使用较为简单,在程序中可以找到“ICDCOMM观测器”,或者找到{ProgramFiles}\huawei\Compatible\icdcommview.bat



2. 点开底下的某个usUnitNo可以看到一个通道信息,其中有ProID值:



如果嫌一个个找太麻烦,可以点击LocalInfo页签查看所有progId:



如果报错的progId在此列表中,则表示当前通道已被占用。

3. 在linux下则可以直接以cti安装用户运行icdcommview:



icdcommview是有一些参数的,如指定输出目录等,但一般我们这么用就足够了,返回信息里有输出结果的文件,用vi访问它,之后输入"/=60000"就可以查询60000的进程号情况



4. 如果查找不到,则表示通道未被占用.需要注意的是icdcommview这个工具有一定的延时性,特别是退出某个通道,大约要两三分钟左右才会显示通道释放,这和平台的握手机制有一定的关系。

5. 在确定progID被占用后,我们需要按进程号找到当前占用它的进程。
目前没有提供相关的命令执行此查询,但我们可以通过icdcomm.log来查找。
在icdcomm.log日志中,一般有如下类似的日志:
[1496:2013-03-2611:34:19]TcpInit(39)OK

6. 这里的TCPINIT后跟的数字即为progID,而最前面的1496就是占用它的pid值,有了pid值,我们就可以通过结束进程的方式强制释放通道。


根因
通信端口被占用的现象很多见,原因也较多,但基本下都跟异常操作有关。
大都是因为某个进程异常退出,但其对应的收发消息通道没有关闭,导致icdcomm没有释放其通道。再次重启时由于通道被占用则报此错误极少的情况下。在icdcomm重启之后仍然无法恢复。如果这类progId是我们常见的,问题比较好排查。比如20是CCS,30是CTISRVER等等。但有些ProgID是应用程序如WEBCC等占用的,并不常见的端口,这时往往会使得环境维护人员产生困惑。

END