23

The GNU coreutils timeout command is extremely handy for certain scripting situations, allowing for using the output of a command if it is quick to run, and skipping it if it would take too long.

How can I approximate the basic behavior of timeout using only POSIX specified utilities?


(I'm thinking it may involve a combination of wait, sleep, kill and who knows what else, but perhaps I'm missing an easier approach.)

9
  • 3
    See Timing out in a shell script, but I don't consider this a duplicate because I requested portability to pre-POSIX systems and I had the requirement of preserving stdin and stdout which some solutions involving background processes rule out. Commented Apr 6, 2016 at 0:15
  • command & pid=$! ; sleep 5 && kill $pid
    – Pandya
    Commented Apr 6, 2016 at 10:14
  • 1
    @Pandya doesn't that introduce a slight race condition, wherein if command finishes rapidly there is a slim chance of the pid being reused by another process starting up before the kill command runs? I wouldn't want that in production code....
    – Wildcard
    Commented Apr 6, 2016 at 18:38
  • Can you explain more about the underlying problem you're trying to solve? Why not just compile the timeout program and use it? Commented Apr 10, 2016 at 22:53
  • 2
    @JamesYoungman, I'm guessing you're not very familiar with writing scripts for portability. Asking for a POSIX-compliant (or POSIX-specified) way of doing something implies that it's intended to be portable. Compiling source code into a binary is emphatically not portable, and, depending on your company security policies, you may not have a compiler installed at all on a production server.
    – Wildcard
    Commented Apr 12, 2016 at 0:32

1 Answer 1

6

My approach would be this one:

  • Execute command as background process 1

  • Execute "watchdog timer" as background process 2

  • Set up a handler to trap a termination signal in the parent shell

  • Wait for both processes to complete. The process that terminates first, sends the termination signal to the parent.

  • The parent's trap handler kills both background processes via job control (one of them has already terminated by definition, but that kill will be a harmless no-op because we are not using PIDs, see below)

I tried to circumvent the possible race condition addressed in the comments by using the shell's job control IDs (which would be unambiguous within this shell instance) to identify the background processes to kill, instead of system PIDs.

#!/bin/sh

TIMEOUT=$1
COMMAND='sleep 5'

function cleanup {
    echo "SIGTERM trap"
    kill %1 %2
}

trap cleanup SIGTERM

($COMMAND; echo "Command completed"; kill $$) &
(sleep $TIMEOUT; echo "Timeout expired"; kill $$) &

wait
echo "End of execution"

Result for TIMEOUT=10 (command terminates before watchdog):

$ ./timeout.sh 10
Command completed
SIGTERM trap
End of execution

Result for TIMEOUT=1 (watchdog terminates before command):

$ ./timeout.sh 1
Timeout expired
SIGTERM trap
End of execution

Result for TIMEOUT=5 (watchdog and command terminate "almost" simultaneously):

./tst.sh 5
Timeout expired
Command completed
SIGTERM trap
End of execution
2
  • This is not POSIX compliant as (a) the function definition should be cleanup() { ...; } and (b) job control is a bash feature not specified by POSIX (though ksh and others have it also). Nice script, though!
    – Wildcard
    Commented Oct 11, 2017 at 4:59
  • You can also do better with timeout="$1"; shift and (exec "$@"; echo "Command completed"; kill $$) rather than re-wordsplitting the argument list.
    – Wildcard
    Commented Oct 11, 2017 at 5:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .