Shell Programming and Scripting

How would you make sure that a shell script (or a portion thereof) does not run (it waits or it terminates with error) when another instance of it is already running?

The simplest way would be to use a lock file - let the contents of a text file act as a traffic cop.

Hmmm... contents of the file?

How would you make sure that, in between the point in time you check the file and the point in time you set the lock, no other process does the same resulting in two processes running?

I'd use the presence or absence of an interlock file and record your shell's process id in the file.
Create the file with /usr/bin/touch for speed and refer to the full hierarchial filename throughout the script (i.e. avoid directory searches). After creating the file append your shell's process id. Read back the file and check the process id to be 100% sure that your instance holds the interlock before processing, otherwise back off.

I like using 'fuser' - making sure there's only ONE pid 'locking' the script.

One problem with this method is someone may be running "cat <script>" and
fuser will show this . So you might have to check the processes that "fuser"
returns and make sure they are indeed running the script.

Something along these lines:

Code:

#!/bin/ksh

thisFILE="$(whence ${0})"
progName="${0##*/}"

     myPID="$$"

     FUSERout=$(fuser ${thisFILE} 2>/dev/null)
     typeset -i numProc=$(echo "${FUSERout}" | nawk '{print NF}')
     if [[ "${numProc}" -gt 1 ]]; then
        echo "${progName}: another instance(s) of [${thisFILE}] is currently still running [$(echo ${FUSERout} | sed -e 's/  */ /g')] - exiting THIS ${myPID}] run."
        exit 1
     fi

Depends on what you mean for "back off".

Suppose that while you write the pid another process is doing the same. This results in the other pid appearing inside the file before or after your pid, the position does not matter here.
Then you check and see another pid:.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Ok, now I got it: the serialization protocol dictates that the pid appearing in line 1 of the interlock file is the one whose process is allowed to go on, while the other processes are inside a wait-and-check loop (well, perhaps it is smarter to just wait $pid1 where pid1 is read from line 1); when the process ends, it removes its pid; then another pid is in line 1... and so on, until the pid queue is empty.

Not bad. Still a bit involved though.

You have to be absolutely sure that the script cannot end without having removed its pid from the queue. An exit handler implemented with trap would be enough, but a SIGKILL would bypass the trap.

I like using fuser too, but:On the plus side, the lock is automatically removed when the process ends or is terminated in any way.