ruby超时和系统命令

我有一个ruby超时，它调用一个系统（bash）命令，如下所示

Timeout::timeout(10) {
  `my_bash_command -c12 -o text.txt`
}

---

但我认为，即使ruby线程被中断，实际的命令仍会在后台运行。。这正常吗？我怎样才能杀死它？

我想你必须手动杀死它：

require 'timeout'

puts 'starting process'
pid = Process.spawn('sleep 20')
begin
  Timeout.timeout(5) do
    puts 'waiting for the process to end'
    Process.wait(pid)
    puts 'process finished in time'
  end
rescue Timeout::Error
  puts 'process not finished in time, killing it'
  Process.kill('TERM', pid)
end

---

<>为了正确地停止生成过程树（不只是父进程），人们应该考虑这样的事情：

def exec_with_timeout(cmd, timeout)
  pid = Process.spawn(cmd, {[:err,:out] => :close, :pgroup => true})
  begin
    Timeout.timeout(timeout) do
      Process.waitpid(pid, 0)
      $?.exitstatus == 0
    end
  rescue Timeout::Error
    Process.kill(15, -Process.getpgid(pid))
    false
  end
end

---

这还允许您跟踪进程状态

这可能有助于其他人实现类似的超时功能，但需要从shell命令收集输出

我已经修改了@shurikk的方法来使用Ruby 2.0和一些来自的代码来收集输出

def exec_with_timeout(cmd, timeout)
  begin
    # stdout, stderr pipes
    rout, wout = IO.pipe
    rerr, werr = IO.pipe
    stdout, stderr = nil

    pid = Process.spawn(cmd, pgroup: true, :out => wout, :err => werr)

    Timeout.timeout(timeout) do
      Process.waitpid(pid)

      # close write ends so we can read from them
      wout.close
      werr.close

      stdout = rout.readlines.join
      stderr = rerr.readlines.join
    end

  rescue Timeout::Error
    Process.kill(-9, pid)
    Process.detach(pid)
  ensure
    wout.close unless wout.closed?
    werr.close unless werr.closed?
    # dispose the read ends of the pipes
    rout.close
    rerr.close
  end
  stdout
 end

---

处理过程、信号和计时器不是很容易。这就是为什么你可以考虑委派这个任务：在Linux新版本：< /P>中使用命令<代码> TimeOuts<代码>

timeout --kill-after=5s 10s my_bash_command -c12 -o text.txt

---

那不是真的。当父ruby进程终止时，运行该命令的子shell应该终止。请给出一个更具体的例子。@BenLee:父进程不会在超时过期时终止。@MladenJablanović，在一个快速实验中，它会终止。我创建了一个ruby文件，除了：

require'timeout'；超时：：超时（100）{

sleep 500`}

。运行它时，我会执行

ps aux | grep sleep`并查看睡眠过程。然后我将SIGKILL发送到ruby进程，然后再次运行

ps aux | grep sleep

，不再看到子进程。@BenLee:请重新阅读我上面的评论。谢谢。实际上Mladen是对的，父进程不会在达到超时时终止（除非在运行命令后没有其他事情要做）。发生的情况是引发Timeout:：Error异常，仅此而已。子外壳仍在运行。即使父进程（ruby）在抛出异常后终止，启动的shell命令仍在运行，它只是从ruby进程重新分配给以PID 1作为其子进程的进程。至少这是Mac OSX上发生的情况。这与示例不同，因为您使用的是'Process.spawn

。使用该命令，子进程*不会*在主进程终止时终止。在等待子流程返回时，它也不会停止应用程序的执行；它并行运行。但是当使用backticks（或

exec`）时，主进程会等待子进程返回，如果主进程终止，则会终止子进程。。OP根本不会终止主进程。问题是由

超时引发的异常是否终止子进程（并且它没有终止）。你是对的，我误解了OP的问题。将我的投票从向下改为向上。（一开始它不允许我更改它，说“除非这个答案被编辑，否则你的投票现在被锁定”，所以我做了一个快速编辑，只添加了一个空格字符，不更改任何内容）。哈哈，然后它允许我撤销编辑，而不恢复我的投票。从某种意义上说，这是一种有趣的系统游戏方式——如果你总是能这样绕过它，“锁”就不是真的。谢谢。好吧，我想这将是不必要的复杂，涵盖这样的边缘投票案件不知道他们为什么要把锁放在开头…杀死树是很重要的，这样做的代码通常应该是这个问题的答案。关于您的解决方案有两点：Process：：kill文档说，终止进程组的信号应该是负的（您的代码将进程组ID设置为负）。另外，Process:：spawn似乎不接受代码块，这使得它不太方便。不过，我认为你的方向是正确的。我认为这个进程。kill（15，-Process.getpgid（pid））==Process.kill（-15，pid），我不记得我在哪里读到过（当然可能是错的）。这里重要的一点是：pgroup=>true我认为使用
Open3.capture*
变体会更容易。我假设它会在超时后自动启动。在我的系统上，语法是
timeout
：例如
timeout 10s，我的\u bash\u命令
。
--kill after
选项特定于发送术语信号后等待的时间量。使用此选项，您仍然需要指定原始的持续时间：
timeout--kill after=5s 10s my_bash_command
@yves:在我的系统上，语法是timeout，这里的语法是相同的，不是吗？或者您想说，
timeout
不接受系统上的任何选项吗？