Automation作业调度问题：Only one instance of etlslave.pl allow to run

最近，集市有个作业调度出了问题，导致作业一直处于Running状态，但是后台进程并没有对应的作业。去检查日志，发现只有作业调度日志，并未脚本执行日志，这表明作业并未实际运行，检查作业调度日志，发现报了一个错，Only one instance of etlslave.pl allow to run，这说明已经有一个实例在运行了，百度谷歌都没有答案，于是自己动手丰衣足食。开始进入分析阶段。

第一步：检查日志 

进入日志目录下，检查日志，只有调度日志，没有脚本执行日志。日志报错Only one instance of etlslave.pl allow to run.

第二步：重新调度 

将作业状态置为Done，重新强制调起，发现无法调起作业。

第三步：检查控制文件 

 进入ETL目录下的DATA目录，检查各个目录下的控制文件的状态，去process目录检查，发现了当日的控制文件，而且控制文件已经从dir.xxxx变成了xxxx.dir，这表明，进程etlrcv.pl已经从receive件下检测到控制文件，然后放置到queue队列里面，然后再进去了process目录。进入receive目录，发现了后续几天的控制文件。于是删除了process目录下的控制文件，然后开始运行后一天的作业，状态仍然一直为Running，这证明了基本的调度是没有问题的。

第四步：深入挖掘 

基本流程走完了，深入分析的第一要怀疑的这个Only one instance of etlslave.pl allow to run是哪里报出来的错误，不是ETL脚本，也不是通用的脚本，一看就大致猜到是Automation的deamon进程里面的报的错误。于是开始检查了精灵进程etlmaster.pl，进一步找到etlslave_unix.pl，然后使用more etlslave_unix.pl|grep instance 查找到Only one instance of etlslave.pl allow to run这个错误提示信息，再进一步查看，发现了这里面有锁的处理，于是立刻想到，由于后台调度的问题，会不会锁了，一开始就考虑过这种可能，但是一直纠结于后台进程的问题。

第五步：处理问题 

 于是立刻进入lock目录，发现了该作业的锁文件，于是删除该锁，重置作业状态，作业进入正常运行状态。查看日志，正常，问题解决。

第六步：总结分析 

遇见问题，首先要定位问题，试错的方式虽然是最容易的，但是却是有代价的，所以从根本上分析问题才是最重要的，分析问题的过程带来对问题本质的更深入的了解，下一步就是深入的去了解Automation的精灵进程，通过详细理解代码，深入了解Automation的调度机制，做到遇见问题心中了然的境界。