命令行命令在一定时间后自动终止命令

本文介绍了命令行命令在一定时间后自动终止命令的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我想在一定时间后自动终止一个命令.我想到了这样的界面:

I'd like to automatically kill a command after a certain amount of time. I have in mind an interface like this:

% constrain 300 ./foo args

哪个会运行带有args"的./foo"，但如果它在 5 分钟后仍在运行，则会自动终止它.

Which would run "./foo" with "args" but automatically kill it if it's still running after 5 minutes.

将这个想法推广到其他约束可能会很有用，例如如果进程使用过多内存，则自动终止该进程.

It might be useful to generalize the idea to other constraints, such as autokilling a process if it uses too much memory.

是否有任何现有的工具可以做到这一点，或者是否有人写过这样的东西?

Are there any existing tools that do that, or has anyone written such a thing?

添加:乔纳森的解决方案正是我所想的，它在 linux 上的作用就像一个魅力，但我无法让它在 Mac OSX 上工作.我摆脱了 SIGRTMIN 让它可以正常编译，但信号只是没有发送到子进程.有人知道如何在 Mac 上进行这项工作吗?

ADDED: Jonathan's solution is precisely what I had in mind and it works like a charm on linux, but I can't get it to work on Mac OSX. I got rid of the SIGRTMIN which lets it compile fine, but the signal just doesn't get sent to the child process. Anyone know how to make this work on Mac?

[已添加:请注意，Jonathan 提供了适用于 Mac 和其他地方的更新.]

[Added: Note that an update is available from Jonathan that works on Mac and elsewhere.]

推荐答案

我参加这个聚会的时间已经很晚了，但我没有看到答案中列出了我最喜欢的技巧.

I've arrived rather late to this party, but I don't see my favorite trick listed in the answers.

在 *NIX 下，alarm(2) 跨 execve(2) 继承，并且 SIGALRM 默认情况下是致命的.因此，您通常可以简单地:

Under *NIX, an alarm(2) is inherited across an execve(2) and SIGALRM is fatal by default. So, you can often simply:

$ doalarm () { perl -e 'alarm shift; exec @ARGV' "$@"; } # define a helper function $ doalarm 300 ./foo.sh args

或者安装一个 简单的 C 包装器来为你做这件事.

or install a trivial C wrapper to do that for you.

优点 只涉及一个PID，机制简单.例如，如果 ./foo.sh 退出太快"并且其 PID 被重新使用，您将不会终止错误的进程.您不需要多个 shell 子进程协同工作，这可以正确完成，但很容易发生竞争.

Advantages Only one PID is involved, and the mechanism is simple. You won't kill the wrong process if, for example, ./foo.sh exited "too quickly" and its PID was re-used. You don't need several shell subprocesses working in concert, which can be done correctly but is rather race-prone.

缺点 时间受限的进程无法操纵它的闹钟(例如，alarm(2)、ualarm(2)、setitimer(2))，因为这可能会清除继承的警报.显然，它也不能阻止或忽略 SIGALRM，尽管对于其他一些方法，SIGINT、SIGTERM 等也是如此.

Disadvantages The time-constrained process cannot manipulate its alarm clock (e.g., alarm(2), ualarm(2), setitimer(2)), since this would likely clear the inherited alarm. Obviously, neither can it block or ignore SIGALRM, though the same can be said of SIGINT, SIGTERM, etc. for some other approaches.

一些(我认为是很老的)系统在 alarm(2) 方面实现了 sleep(2)，即使在今天，一些程序员仍然使用 alarm(2) 作为 I/O 和其他操作的粗略内部超时机制.但是，根据我的经验，此技术适用于您想要限制时间的绝大多数流程.

Some (very old, I think) systems implement sleep(2) in terms of alarm(2), and, even today, some programmers use alarm(2) as a crude internal timeout mechanism for I/O and other operations. In my experience, however, this technique is applicable to the vast majority of processes you want to time limit.