启动或确保在应用程序/服务器重新启动时运行延迟作业

我们必须使用delayed_job(或其他一些后台作业处理器)在后台运行作业,但我们不允许更改服务器上的启动脚本/启动级别.这意味着如果提供程序重新启动服务器,则不保证守护程序仍然可用(因为守护程序将由每个部署仅运行一次的capistrano配方启动).

目前,我能够想到确保delayed_job守护程序始终运行的最佳方法是向我们的Rails应用程序添加初始化程序,以检查守护程序是否正在运行.如果它没有运行,那么初始化器启动守护进程,否则,它就会离开它.

因此,问题是我们如何检测到Delayed_Job守护程序是从脚本内部运行的？(我们应该能够相当容易地启动一个守护进程,我不知道如何检测一个守护进程是否已经激活).

有人有主意吗？

此致,伯尼

基于下面的答案,这就是我提出的.只需将它放在config/initializers中就可以了:

#config/initializers/delayed_job.rb

DELAYED_JOB_PID_PATH = "#{Rails.root}/tmp/pids/delayed_job.pid"

def start_delayed_job
  Thread.new do 
    `ruby script/delayed_job start`
  end
end

def process_is_dead?
  begin
    pid = File.read(DELAYED_JOB_PID_PATH).strip
    Process.kill(0, pid.to_i)
    false
  rescue
    true
  end
end

if !File.exist?(DELAYED_JOB_PID_PATH) && process_is_dead?
  start_delayed_job
end

小智.. 9

一些更清理的想法:不需要"开始".你应该拯救"没有这样的过程",以便在出现其他问题时不要启动新进程.拯救"没有这样的文件或目录"以简化条件.

DELAYED_JOB_PID_PATH = "#{Rails.root}/tmp/pids/delayed_job.pid"

def start_delayed_job
  Thread.new do 
    `ruby script/delayed_job start`
  end
end

def daemon_is_running?
  pid = File.read(DELAYED_JOB_PID_PATH).strip
  Process.kill(0, pid.to_i)
  true
rescue Errno::ENOENT, Errno::ESRCH   # file or process not found
  false
end

start_delayed_job unless daemon_is_running?

请记住,如果您启动多个工作程序,此代码将不起作用.并查看script/delayed_job的"-m"参数,该参数与守护进程一起产生监视进程.

1> 小智..：

---

一些更清理的想法:不需要"开始".你应该拯救"没有这样的过程",以便在出现其他问题时不要启动新进程.拯救"没有这样的文件或目录"以简化条件.

DELAYED_JOB_PID_PATH = "#{Rails.root}/tmp/pids/delayed_job.pid"

def start_delayed_job
  Thread.new do 
    `ruby script/delayed_job start`
  end
end

def daemon_is_running?
  pid = File.read(DELAYED_JOB_PID_PATH).strip
  Process.kill(0, pid.to_i)
  true
rescue Errno::ENOENT, Errno::ESRCH   # file or process not found
  false
end

start_delayed_job unless daemon_is_running?

请记住,如果您启动多个工作程序,此代码将不起作用.并查看script/delayed_job的"-m"参数,该参数与守护进程一起产生监视进程.

2> Tony Fonteno..：

---

检查是否存在守护进程PID文件(File.exist? ...).如果它在那里然后假设它正在运行其他启动它.

---

您必须查找PID文件*和*如果进程表中存在具有该ID的条目,*AND*可能还会检查它是否具有正确的名称.前两个测试很可能是真的,如果系统意外停止并留下陈旧的PID文件,那么该ID的进程就是预期的那个.也许更快的测试方法是让守护进程响应某种心跳请求.发送请求,如果得到正确的响应,您就知道您需要的代码正在运行.在这种情况下,实际上不需要PID文件测试.