UNIX for Dummies Questions & Answers

Does anyone know it it is possible to start a program with a timeout, so that it is automatically killed if the timeout expires? If yes, how?

You can do this, but do not do it as a privleged user, there is a risk of clobbering a valid running process.

Code:

/path/to/myprogram arg1 arg2  &
last_pid=$!
sleep 100  # wait one hundred seconds
kill -TERM $last_pid   # this will kill only processes you own - if you're not privileged

This whole thing is not the best possible idea - are you sure sending SIGTERM to these processes is not going to wreck some data?

I think this should be OK in my case.
The process in this case is an optimization program with an indata file. I have a shell script which runs this program for a bunch of different indata files in a directory. The reason I wanted a timeout is that the runtime of the program is very large in some cases and then I have to manually kill them. That's why I wanted to use a timeout so that this issue is handled automatically. I will add this code in my shell script and try it. Thanks.
Out of curiousity, do you know any other way?

What happens if the process has already finished before sleep is finished (i.e. before the timeout)? Then we try to kill a nonexisting pid.

The problem is: on a busy system the pid may possibly be another process. You would in trouble if that process were a process you owned. So, try to keep the sleep value reasonably close to what your process actually needs to complete its job.

i have two solutions for the approach ...

first)

once you are sure that the process you have initiated to be killed after 'x' seconds.. then inbuilt a infinite loop logic in the program you run ... after it had completed all its required computations let the program to run in a infinite loop
so no chance of another valid process being killed.

second)

prior to sending SIGTERM signal to the process checking for the time stamp that is for sure would prevent terminating a valid process

Actually my point of view is:
If you need to run the job, run the job to completion, don't impose artificial time constraints. If the process takes too long, try either threads or multitasking - dividing the job into smaller parts. Or, if you can kill the job safely, that means you don't really need the job scheduled as it is anyway. nice it and let it run all day in background.

This kill it model of job control is not good.

This is an odd thing to do. But I just got this script to work:

Code:

#! /usr/bin/ksh

sleep 200 ; kill -term -$$ &
sleep 7
kill -term -$$

One of my sleep processes represents a process that might run too long. The other sleep process is the timer. Either process could play either role, but I envisioned that first line as the timer and the second as the process to be timed. One of the processes will probably finish first and then run the "kill -term -$$". This will kill the process group. On a multiprocessor system simultaneous kills may occur, but the kernel will ensure that they happen serially. There is no race condition here. This depends on the shell putting all processes in a script into a single process group. So neither sleep process could be replaced with another shell script because it would become a new process group.