Making sure only one instance of a script is running

Shell Programming and Scripting
1

so i have a script that takes a while to complete and its cpu intensive. this script is being used by several users. i want to make sure only 1 user can run this script at any given time.

i originally thought of running a while loop to egrep the process table of the PID ($$) of the process, but im not sure if that's going to be efficient. i want to make sure the script does not mistaking someone editing the script as a running process. so im excluding the common editing programs.

im searching for a solution that will be usable across all unix systems. here's what i have tried so far:

procname$(ps -ef | egrep "processname" | egrep -vc "grep| vi | ed | emacs")
if [ ${procname} -gt 0 ] ;then
echo "Script is currently in progress..aborting..."
exit 3
fi
2

You could try using a .pid file and check it at the top of your script like this:

#!/bin/sh

NAME=$(basename "$0")

if [ -f /var/run/"$NAME.pid" ] &&
  ps -p $(cat /var/run/"$NAME.pid") >/dev/null 2>&1
then
   echo "Script is currently in progress..aborting..."
   exit 3
fi

trap 'rm -f /var/run/"$NAME.pid"' EXIT
echo $$ > /var/run/"$NAME.pid"

...
1 Like
3

All designs that try to check for a lock-file or pid-file are flawed. They are subjective to racecondition
The problem is that you can not check for the existence of a file and the creation of that file in an atomic action. And in between of those two actions another instance can run.

Some more info

2 Likes
4

Interesting link, I usually don't need portability and use flock(1) for my own scripts.

The method using mkdir from that FAQ looks like it would be more reliable and still portable:

 lockdir=/tmp/myscript.lock
 if mkdir "$lockdir"
 then
     # Remove lockdir when the script finishes, or when it receives a signal
     trap 'rm -rf "$lockdir"' 0    # remove directory when script finishes

     # Optionally create temporary files in this directory, because
     # they will be removed automatically:
     tmpfile=$lockdir/filelist
 else
     echo "Script is currently in progress..aborting..."
     exit 3
 fi
1 Like
5

I use this block of code early in scripts that need to be run separately:-

# Set up / test lock file.  Hold lock for whole script
lockfile="/var/lock/my-lock-file"
[ ! -f $lockfile ] && touch $lockfile
exec 13>> $lockfile

flock -w 30 -x 13                                           # Do you feel locky?

if [ $? -ne 0 ]
then
   echo "$0 bypassed due to lock" >> $tracefile
   logger "$0 bypassed due to lock"
   exit 666
else
   echo "$0 has the the lock" >> $tracefile
   logger "$0 has the the lock"
fi

Naturally, I use a suitable file name for the lock file so that it is easy to recognise and re-use/avoid for other scripts. It seems to work for me. The tracefile variable and other things have already been set.

The -w flag on flock means that it will wait on file descriptor 13 for 30 seconds trying to get an exclusive lock (the -x flag) The file descriptor is left open by the >> redirector so the lock persists.

If the process is killed off ungracefully (i.e. a kill -9) then the file is then closed and the lock released, else it is closed when the script terminates gracefully or can be closed earlier if that is appropriate with exec 13>&- It negates the need for the trap ....... 0 which leaves you free to use it for something else if that is appropriate.

As they say, Tim Toady

Robin

1 Like
6

Yes flock(1) is the right way to do this.

The OP is after a portable solution, so lets test for executable /usr/bin/flock
and use that when available but revert to the mkdir method on systems without it:

if [ -x /usr/bin/flock ] || [ -x /bin/flock ]
then
    # If the env var $FLOCKER is not set,  then execute flock and
    # grab an exclusive non-blocking lock (using the script
    # itself as the lock file) before re-execing itself with the right
    # arguments.   It also sets the FLOCKER env var to the right value
    # so it doesn't run again.  Otherwise exit with status 3

    [ "${FLOCKER}" != "$0" ] && 
        exec env FLOCKER="$0" flock -E 3 -en  "$0"  "$0" "$@" || :
else
    # Here, even when two processes call mkdir at the same time, 
    # only one process can succeed at most. This atomicity of 
    # check-and-create is ensured at the operating 
    # system kernel level.

    lockdir=/tmp/myscript.lock
    if mkdir "$lockdir"
    then
        # Remove lockdir when the script finishes, or when it receives a signal

        trap 'rm -rf "$lockdir"' 0    # remove directory when script finishes
    else
        exit 3
    fi
fi
2 Likes
7

Actually - you can. The underlying filesystem calls support it (O_CREAT | O_EXCL), some shells have extensions for it, and for those who don't, there are ways to cheat a little - mkdir and mkfifo are atomic, they succeed and create a new filename or fail and don't, you can use them to "mutex" the creation of a PID file.

That a race condition may exist doesn't actually make ps | grep | awk | sed | cut | kitchen | sink | when | will | the | madness | end better than PID files, either. That's far from atomic, itself. It's also complicated, brittle, unreliable, and unportable on top of that.

There's a reason PID file is a de facto standard.

8

Actually, how about this as a simple mutex method?

MASK=$(umask)
umask 773

# PID file will be atomically created as read-only
# The first shell can write to it, but no others
if ! echo "$$" > /tmp/pidfile
then
        echo "Failed to get PID file"
        read PID < /tmp/pidfile
        echo "PID $PID has it"
        exit 1
fi

umask "$MASK"


trap "rm -f /tmp/$$" EXIT

# everything else

Still one potential race -- the file may exist but still be empty when other shells try and read it. That's not a fatal flaw though.

Another bigger problem is that root can plow straight through ignoring all permissions to write to that read-only file. Only run as a user.

1 Like