Re: New util suggestion: timeout
Philip Rowlands [EMAIL PROTECTED] wrote: I'd be happy to learn if there's something else already in common use. Probably not too common, but there is this: URL:http://cr.yp.to/daemontools/softlimit.html The -t option limits CPU time, though, not wall-clock time. How would you limit wall-clock time? Schedule SIGALRM with setitimer and then exec the given command? paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: New util suggestion: timeout
[EMAIL PROTECTED] (Paul Jarc) writes: How would you limit wall-clock time? Schedule SIGALRM with setitimer and then exec the given command? I've long used a command of my own called 'alarm' that just does that. However, this strategy doesn't always work well if the command has subprocesses, since the signal is sent only to the exec'ed process. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: New util suggestion: timeout
Paul Eggert [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Paul Jarc) writes: How would you limit wall-clock time? Schedule SIGALRM with setitimer and then exec the given command? I've long used a command of my own called 'alarm' that just does that. However, this strategy doesn't always work well if the command has subprocesses, since the signal is sent only to the exec'ed process. It also fails if the command uses setitimer itself. That could be handled by forking and having the parent send SIGTERM to the child when it gets its own SIGALRM. To handle the child processes, a new process group could be created, but that might interfere with other things. paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: New util suggestion: timeout
On Mon, 28 Jun 2004, Paul Jarc wrote: How would you limit wall-clock time? Schedule SIGALRM with setitimer and then exec the given command? I've long used a command of my own called 'alarm' that just does that. However, this strategy doesn't always work well if the command has subprocesses, since the signal is sent only to the exec'ed process. It also fails if the command uses setitimer itself. That could be handled by forking and having the parent send SIGTERM to the child when it gets its own SIGALRM. To handle the child processes, a new process group could be created, but that might interfere with other things. Yes, keep the parent hanging around to handle the killing, particularly because you might want a two-stage kill (SIGTERM, sleep(5), SIGKILL). Process group helps when there might be sub-sub-processes, but as you say that has the potential to interfere with things which don't expect it, so perhaps make it a command-line parameter. So far then, I've got as potential command line args: - Seconds to sleep until first signal - Which signal to deliver at timeout #1 - Seconds to sleep until second signal (KILL) - Optionally create process group and kill all children - Exit status for the timeout condition The most common use I've got right now (and this is what prompted me to suggest it in the first place) is: $ timeout 10 ssh otherhost 'some random command' Cheers, Phil ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
New util suggestion: timeout
What: timeout, executes the sub-command a-la GNU time/nice, but takes arguments to control the amount of wallclock time the process is allowed. Why: - ulimit for real time - No current util (GNU or otherwise) widely distributed (AFAIK) - Useful in scripting, particularly with network apps I was surprised to find lacking, when writing a shell script, that no simple app exists for constraining how long apps will run, so this is a proposal to write one for coreutils, although I'd be happy to learn if there's something else already in common use. Feedback is appreciated; I'll come up with some example invocations and use cases if there's enough interest. Cheers, Phil ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
