运维经验分享（四）--关于 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服务控制脚本第三次优化》