在应用程序和数据库有机会停止之前，我有一种RHEL 6.4服务器发送TERM和KILL信号太快的情况。 看起来Upstart过早地把控制权交给了sysv-rc脚本。
为了解决这个问题，我尝试在Upstartconfiguration中添加sleep和logger命令。 pre-script节写入syslog，但从未完成，因为系统在10秒内重新启动。 我还添加了一个被忽略的kill timeout 。
# cleanup at system shutdown # Does stop all on apps, stops monit instances, then does a clean. start on runlevel [016] console output kill timeout 120 task pre-start script logger -s -t "arcsight-services-stopall" "Running pre-start..." /etc/init.d/arcsight_services stop sleep 60 end script script logger -s -t "arcsight-services-stopall" "Running script..." /etc/init.d/arcsight_services shutdown monit /etc/init.d/arcsight_services clean all end script
我知道Upstart是假设并行启动/暂停过程，但它只是瘫痪我的debugging尝试。
在RHEL 6下，发出后执行的脚本的确切顺序是什么： shutdown -r now ？
shutdown -r now ????? /etc/init/rc.conf ） /etc/rc.d/rc ） ????? /etc/rc3.d/K* ） /etc/rc6.d/S* ） ????? 其他/etc/init/*.conf脚本在哪里被调用？
更新：在解剖/etc/rc.d/rc ，我发现，如果我touch /var/run/confirm ，进程进入交互模式，然后我的睡眠和logging器命令似乎执行。 这让我感到困惑，因为我认为，那时Upstart已经把控制权交给了系统pipe理员。
虽然这个答案没有解决在RHEL 6closures期间执行的脚本的顺序，但它在正常停止之前确实解决了系统查杀过程的问题。
/etc/init/arcsight-services-stopall.conf：
# cleanup at system shutdown # Does stop all on apps, stops monit instances, then does a clean. start on starting rc RUNLEVEL=[016] task kill timeout 330 pre-start script logger -s -t "ArcSight" "ArcSight ESM shutdown initiated..." /etc/init.d/arcsight_services shutdown all /etc/init.d/arcsight_services shutdown monit /etc/init.d/arcsight_services clean all sleep 300 end script script logger -s -t "ArcSight" "ArcSight ESM shutdown complete." end script
关键是修改start on starting rc RUNLEVEL=[016] 。 通过在/etc/init/rc.conf刚启动的时候启动这个脚本，在执行sysv-rc脚本之前，它会阻塞5分钟。 希望在这5分钟内，所有的ArcSight数据库和应用程序都能正常停止。 testing表明，一切都在3分钟内停止，所以5分钟应该是一个安全的延迟。
看到一款价值数百万美元的产品需要客户破解总是令人高兴的。