运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析-阿里云开发者社区

开发者社区> 开发与运维> 正文

运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析

简介:

运维经验分享作为一个专题,目前共7篇文章

  1. 运维经验分享(一)-- Linux Shell之ChatterServer服务控制脚本

  2. 运维经验分享(二)-- Linux Shell之ChatterServer服务控制脚本二次优化

  3. 运维经验分享(三)-- 解决Ubuntu下crontab不能正确执行Shell脚本的问题(一)

  4. 运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析

  5. 运维经验分享(五)-- 改进的java进程管理的服务控制脚本

  6. 运维经验分享(六)-- 深究crontab不能正确执行Shell脚本的问题(二)

  7. 运维经验分享(七)-- Linux Shell之ChatterServer服务控制脚本第三次优化

====================================分割线======================================

ChatterServer 之所以有如此多版和遇到这么多问题,跟java进程还有很大的关系,此次面临的问题和分析思路总结如下,欢迎各位补充。

停止java进程可能面临的问题:

  1. 以kill pid的方式停止java进程,java进程在等待java进程内部结束,因此没有立即结束,从而导致原java程序监听的端口可能没有释放,原java进程的pid也可能依然存在

  2. 在原java进程没有立即结束的情况下,再重新启动这个java进程就会产生错误,这些错误包括无法重新监听端口,甚至是直接启动失败

  3. 启动java进程可能面临的问题:

  4. 用java命令启动java进程,java进程返回结果为成功,但实际不成功(需要注意确认“用java命令启动java进程”返回的执行结果是java自身返回的,还是人工编写的程序返回的)

上面描述的一些进一步解释、术语和例子:

  1. java进程是指由人工编写的一些java程序,其中不能保证程序里面的异常全部捕获并处理,例如如果无法监听端口返回正确的错误返回值并退出

  2. 以kill pid的方式:kill `cat $PIDFILE`

  3. 用java命令启动java进程:java -jar somename.jar $ARGS

原有的启动java进程的流程

  1. 启动进程有两种情况,第一次启动(首次启动),停止进程后再次启动(重新启动),因此可以考虑将这两种情况综合在一起考虑,即不区分之前是否启动过或停止过,把这些情况都考虑进去

  2. 判断当前系统中的特定目录下是否存在pid文件或者锁

  3. 判断当前系统中是否已经存在java进程,判断的依据是从系统中检测java进程pid是否存在,如ps,而不是根据pid文件或者锁判断

  4. 判断当前系统中是否已经监听端口号,因为端口号可能由别的程序(如果pid不存在,则该端口号不会由它自己占用)占用

  5. 启动java进程(大部分程序都会保证此处能启动成功,可参考/etc/init.d/functions,行270,1-8),如果返回结果为成功,则输出成功并创建pid文件和锁,如果不成功,则输出不成功,不再尝试再次启动

原有的停止java进程的流程

  1. 如果找到pid,先发送TERM信号,暂停100000微秒(usleep 100000),如果人工预先知道需要继续延迟,则延迟自定义秒数,如果没有杀死(即依然能检测到系统中存在此pid)则再发送KILL信号,再次暂停100000微秒

  2. 再次检测到系统中是否存在此pid,如果不存在则输出成功并移除pid文件和锁,如果存在则输出不成功

  3. 如果找不到pid,则输出程序没有在运行

根据以上问题重新设计启动java进程的流程(主要问题所在)

  1. 启动进程有两种情况,第一次启动(首次启动),停止进程后再次启动(重新启动),因此可以考虑将这两种情况综合在一起考虑,即不区分之前是否启动过或停止过,把这些情况都考虑进去

  2. 判断当前系统中的特定目录下是否存在pid文件(原有设计中没有锁,故此处不使用锁)

  3. 判断当前系统中是否已经存在java进程,判断的依据是从系统中检测java进程pid是否存在,如test -d /proc/$pid,ps,而不是根据pid文件或者锁判断

  4. 判断当前系统中是否已经监听端口号,因为端口号可能由别的程序(如果pid不存在,则该端口号不会由它自己占用)占用

  5. 启动java进程(大部分程序都会保证此处能启动成功,可参考/etc/init.d/functions,行270,1-8),如果返回结果为成功,从系统中检测java进程pid是否存在,如果pid存在则输出成功并创建pid文件(原有设计中没有锁,故此处不使用锁),如果pid不存在,则再次启动java进程,移除“如果不成功,则输出不成功,不再尝试再次启动”。

根据以上问题重新设计停止java进程的流程

  1. 针对java进程没有杀死的可能性,现做出如此修改,如果找到pid,先发送TERM信号,暂停100000微秒(usleep 100000),已经预先知道需要继续延迟,延迟5秒,如果没有杀死(即依然能检测到系统中存在此pid)则再发送KILL信号,再次暂停100000微秒

  2. 再次检测到系统中是否存在此pid,如果不存在则输出成功并移除pid文件(原有设计中没有锁,故此处不使用锁),如果pid依然存在则再尝试kill -9(The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.当前假设认为-9比kill更加强制)

  3. 如果找不到pid,则输出程序没有在运行

--end--

====================================分割线======================================

运维经验分享作为一个专题,目前共7篇文章

  1. 运维经验分享(一)-- Linux Shell之ChatterServer服务控制脚本

  2. 运维经验分享(二)-- Linux Shell之ChatterServer服务控制脚本二次优化

  3. 运维经验分享(三)-- 解决Ubuntu下crontab不能正确执行Shell脚本的问题(一)

  4. 运维经验分享(四)--关于 java进程管理的服务控制脚本编程思路分析

  5. 运维经验分享(五)-- 改进的java进程管理的服务控制脚本

  6. 运维经验分享(六)-- 深究crontab不能正确执行Shell脚本的问题(二)

  7. 运维经验分享(七)-- Linux Shell之ChatterServer服务控制脚本第三次优化




本文转自 urey_pp 51CTO博客,原文链接:http://blog.51cto.com/dgd2010/1677155,如需转载请自行联系原作者


版权声明:本文首发在云栖社区,遵循云栖社区版权声明:本文内容由互联网用户自发贡献,版权归用户作者所有,云栖社区不为本文内容承担相关法律责任。云栖社区已升级为阿里云开发者社区。如果您发现本文中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,阿里云开发者社区将协助删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章