OSSCE脚本引发的重大问题，记在这里以示警戒

今天发生的一件大事，早上9点多，在线服务的机器有一半不能访问了。结果查看大多数的java进程被杀死，jboss服务器停掉。也有的机器其它服务被停止。

最初怀疑是被入侵了。因为同时发生状态一致的宕机，除非是时间BUG，否则如何那么多机器都同时停止(已经排除人为操作原因)。

最后和安全部门联系，是否有统一的操作，结果他们反映地那个时间段统一停止了安全模块OSSCE，但它为什么会导致JAVA应用和其它服务停止呢？

最后分析OSSCE的启动脚本，才发现问题的所在：

这个很烂的脚本在启动时开了一个lock，它不象其它软件都是以进程或模块名为文件名的，比如mysql.lock.这个烂人写的脚本是以OSSCE当前进程的进程ID为文件名,比如当前进程ID为3333,则生成3333.pid,里面的内容就是进程ID。

TMD的，如果你非要以进程号作为文件名你直接touch一个0字节的文件从文件名就可以获取这个文件表示的进程ID了。还多此一举再往文件中写进程号。

关键是这个烂程序经常会自动crash.所以没有调用stop,也就没有调用清除文件的命令。经过多次自动crash，多次手工重启后，在一个目录下留下大量的以进程号为文件名的文件。原来的进程号如果积累多了就和当前系统中很多进程的进程号相同。因为之前都是自动crash然后被重启的，所以没有手工调用stop，这次手动调用stop时，一次性清楚目录中留下来的大量的以前的$PID.pid的文件同时根据文件中的pid(其实就是和文件名中的$PID一致)一个个去kill,结果把当前进程中的很多进程给杀死了。

找到问题，但后续工作很麻烦，那么多的机器，到底哪台机器的哪个进程被杀掉，无法统计。只能一一重启。

这个烂人，你就不会以一个固定文件名为lock,然后每次向其中写入当前pid吗？真是脑残啊。还特别在stop时写个脚本列举目录下的所有文件，要是用一个固定文件名用得着列举所有文件吗？