![如何防止 Upstart 启动脚本中出现竞争条件?](https://linux22.com/image/821088/%E5%A6%82%E4%BD%95%E9%98%B2%E6%AD%A2%20Upstart%20%E5%90%AF%E5%8A%A8%E8%84%9A%E6%9C%AC%E4%B8%AD%E5%87%BA%E7%8E%B0%E7%AB%9E%E4%BA%89%E6%9D%A1%E4%BB%B6%EF%BC%9F.png)
我正在开发一个需要两个 Upstart 作业的包:一个启动守护进程,另一个启动支持守护进程如果配置文件需要它。确定是否应启动支持守护进程的逻辑涉及使用sed
和朋友处理配置文件,这会导致 Upstart 的守护进程检测出现问题(Upstart 无法区分 PID),因此expect fork
和expect daemon
没有用。不幸的是,这意味着 Upstart 会将的第一次调用检测sed
为第一个 PID,并在支持守护进程完全初始化之前立即启动主作业。由于环境配置不当,这经常导致主作业过早终止。
在这种情况下,有什么方法可以防止 Upstart 过早启动主要工作?
expect stop
看起来它很接近我需要的,但是我不明白如何在不终止其中一个守护进程的情况下发出该信号,这两个守护进程都不会自行生成 SIGSTOP 信号。
答案1
简单 - 使用pre-start
节来执行所有sed
检查。如果pre-start
确定不应启动支持守护进程,则让它简单调用stop
(这会强制 Upstart不是继续启动该作业)。Upstart Cookbook 中有一个例子:
http://upstart.ubuntu.com/cookbook/#pre-start
请注意,Upstart 仅对exec
和script
节执行 PID 跟踪(换句话说,这是作业的“主要”部分) - 的 PID pre-start
,post-stop
等人不会被追踪。请参阅http://upstart.ubuntu.com/cookbook/#expect
答案2
这个问题的解决方案最终是Upstart 文档:
创建一个启动后部分,执行一些检查,并且仅在服务“准备就绪”后返回。