I prefer to use hard links.

lockfile=/var/lock/mylock
tmpfile=$lockfile.$$
echo $$ > $tmpfile
if ln $tmpfile $lockfile 2>&-; then
 echo locked
else
 echo locked by $(<$lockfile)
 rm $tmpfile
 exit
fi
trap "rm $tmpfile $lockfile" 0 1 2 3 15
# do what you need to

Hard links are atomic over NFS and for the most part, mkdir is as well. Using mkdir(2) or link(2) are about the same, at a practical level; I just prefer using hard links because more implementations of NFS allowed atomic hard links than atomic mkdir. With modern releases of NFS, you shouldn't have to worry using either.

I understand that mkdir is atomic, so perhaps:

lockdir=/var/tmp/myapp
if mkdir $lockdir; then
 # this is a new instance, store the pid
 echo $$ > $lockdir/PID
else
 echo Job is already running, pid $(<$lockdir/PID) >&2
 exit 6
fi

# then set traps to cleanup upon script termination 
# ref http://www.shelldorado.com/goodcoding/tempfiles.html
trap 'rm -r "$lockdir" >/dev/null 2>&1' 0
trap "exit 2" 1 2 3 13 15

An easy way is to use lockfile coming usually with the procmail package.

LOCKFILE="/tmp/mylockfile.lock"
# try once to get the lock else exit
lockfile -r 0 "$LOCKFILE" || exit 0

# here the actual job

rm -f "$LOCKFILE"

sem which comes as part of the GNU parallel tools may be what you're looking for:

sem [--fg] [--id <id>] [--semaphoretimeout <secs>] [-j <num>] [--wait] command

As in:

sem --id my_semaphore --fg "echo 1 ; date ; sleep 3" &
sem --id my_semaphore --fg "echo 2 ; date ; sleep 3" &
sem --id my_semaphore --fg "echo 3 ; date ; sleep 3" &

outputting:

1
Thu 10 Nov 00:26:21 UTC 2016
2
Thu 10 Nov 00:26:24 UTC 2016
3
Thu 10 Nov 00:26:28 UTC 2016

Note that order isn't guaranteed. Also the output isn't displayed until it finishes (irritating!). But even so, it's the most concise way I know to guard against concurrent execution, without worrying about lockfiles and retries and cleanup.

I use dtach.

$ dtach -n /tmp/socket long_running_task ; echo $?
0
$ dtach -n /tmp/socket long_running_task ; echo $?
dtach: /tmp/socket: Address already in use
1

I use the command-line tool "flock" to manage locks in my bash scripts, as described here and here. I have used this simple method from the flock manpage, to run some commands in a subshell...

 (
 flock -n 9
 # ... commands executed under lock ...
 ) 9>/var/lock/mylockfile

In that example, it fails with exit code of 1 if it can't acquire the lockfile. But flock can also be used in ways that don't require commands to be run in a sub-shell :-)

Don't use a file.

If your script is executed like this e.g.:

bash my_script

You can detect if it's running using:

running_proc=$(ps -C bash -o pid=,cmd= | grep my_script);
if [[ "$running_proc" != "$$ bash my_script" ]]; do 
 echo Already locked
 exit 6
fi

Using FLOM (Free LOck Manager) tool, serializing commands becomes as easy as running

flom -- command_to_serialize

FLOM allows you to implement more sofisticate use cases (distributed locking, readers/writers, numeric resources, etc...) as explained here: http://sourceforge.net/p/flom/wiki/FLOM%20by%20examples/

Here is something I sometimes add on a server to easily handle race conditions for any job's on the machine.
It is simmilar to Tim Kennedy's post, but this way you get race handling by only adding one row to each bash script that needs it.

Put the content below in e.g /opt/racechecker/racechecker :

ZPROGRAMNAME=$(readlink -f $0)
EZPROGRAMNAME=`echo $ZPROGRAMNAME | sed 's///_/g'`
EZMAIL="/usr/bin/mail"
EZCAT="/bin/cat"

if [ -n "$EZPROGRAMNAME" ] ;then
 EZPIDFILE=/tmp/$EZPROGRAMNAME.pid
 if [ -e "$EZPIDFILE" ] ;then
 EZPID=$($EZCAT $EZPIDFILE)
 echo "" | $EZMAIL -s "$ZPROGRAMNAME already running with pid $EZPID" alarms@someemail.com >>/dev/null
 exit -1
 fi
 echo $$ >> $EZPIDFILE
 function finish 
 rm $EZPIDFILE
 
 trap finish EXIT
fi

Here is how to use it. Note the row after the shebang:

 #/bin/bash
 . /opt/racechecker/racechecker
 echo "script are running"
 sleep 120

The way it works is that it figures out the main bashscript file name and creates a pidfile under "/tmp". It also adds a listener to the finish signal.
The listener will remove the pidfile when the main script are properly finishing.

Instead if a pidfile exist when an instance are launched, then the if statement containing the code inside the second if-statement will be executed. In this case I have decided to launch an alarm mail when this happens.

What if the script crashes

A further exercise would be to handle crashes. Ideally the pidfile should be removed even if the main-script crashes for any reason, this are not done in my version above. That means if the script crashes the pidfile would have to be manually removed to restore functionality.

In case of system crash

It is a good idea to store the pidfile/lockfile under for example /tmp. This way your scripts will definently continue to execute after a system crash since the pidfiles will always be deleted on bootup.

For actual use, you should use the top voted answer.

However, I want to discuss some various broken and semi-workable approaches using ps and the many caveats they have, since I keep seeing people use them.

This answer is really the answer to "Why not use ps and grep to handle locking in the shell?"

Broken approach #1

First, an approach given in another answer that has a few upvotes despite the fact that it does not (and could never) work and was clearly never tested:

running_proc=$(ps -C bash -o pid=,cmd= | grep my_script);
if [[ "$running_proc" != "$$ bash my_script" ]]; do 
 echo Already locked
 exit 6
fi

Let's fix the syntax errors and the broken ps arguments and get:

running_proc=$(ps -C bash -o pid,cmd | grep "$0");
echo "$running_proc"
if [[ "$running_proc" != "$$ bash $0" ]]; then
 echo Already locked
 exit 6
fi

This script will always exit 6, every time, no matter how you run it.

If you run it with ./myscript, then the ps output will just be 12345 -bash, which doesn't match the required string 12345 bash ./myscript, so that will fail.

If you run it with bash myscript, things get more interesting. The bash process forks to run the pipeline, and the child shell runs the ps and grep. Both the original shell and the child shell will show up in the ps output, something like this:

25793 bash myscript
25795 bash myscript

That's not the expected output $$ bash $0, so your script will exit.

Broken approach #2

Now in all fairness to the user who wrote broken approach #1, I did something similar myself when I first tried this:

if otherpids="$(pgrep -f "$0" | grep -vFx "$$")" ; then
 echo >&2 "There are other copies of the script running; exiting."
 ps >&2 -fq "$otherpids//$'n'/ " # -q takes about a tenth the time as -p
 exit 1
fi

This almost works. But the fact of forking to run the pipe throws this off. So this one will always exit, also.

Unreliable approach #3

pids_this_script="$(pgrep -f "$0")"
if not_this_process="$(echo "$pids_this_script" | grep -vFx "$$")"; then
 echo >&2 "There are other copies of this script running; exiting."
 ps -fq "$not_this_process//$'n'/ "
 exit 1
fi

This version avoids the pipeline forking problem in approach #2 by first getting all PIDs that have the current script in their command line arguments, and then filtering that pidlist, separately, to omit the PID of the current script.

This might work...providing no other process has a command line matching the $0, and providing the script is always called the same way (e.g. if it's called with a relative path and then an absolute path, the latter instance will not notice the former).

Unreliable approach #4

So what if we skip checking the full command line, since that might not indicate a script actually running, and check lsof instead to find all the processes that have this script open?

Well, yes, this approach is actually not too bad:

if otherpids="$(lsof -t "$0" | grep -vFx "$$")"; then
 echo >&2 "Error: There are other processes that have this script open - most likely other copies of the script running. Exiting to avoid conflicts."
 ps >&2 -fq "$otherpids//$'n'/ "
 exit 1
fi

Of course, if a copy of the script is running, then the new instance will start up just fine and you'll have two copies running.

Or if the running script is modified (e.g. with Vim or with a git checkout), then the "new" version of the script will start up with no problem, since both Vim and git checkout result in a new file (a new inode) in place of the old one.

However, if the script is never modified and never copied, then this version is pretty good. There's no race condition because the script file already has to be open before the check can be reached.

There can still be false positives if another process has the script file open, but note that even if it's open for editing in Vim, vim doesn't actually hold the script file open so won't result in false positives.

But remember, don't use this approach if the script might be edited or copied since you'll get false negatives i.e. multiple instances running at once - so the fact that editing with Vim doesn't give false positives kind of shouldn't matter to you. I mention it, though, because approach #3 does give false positives (i.e. refuses to start) if you have the script open with Vim.

So what to do, then?

The top-voted answer to this question gives a good solid approach.

Perhaps you can write a better one...but if you don't understand all the problems and caveats with all the above approaches, you're not likely to write a locking method that avoids them all.

Check my script ...

You may LOVE it....

[rambabu@Server01 ~]$ sh Prevent_cron-OR-Script_against_parallel_run.sh
Parallel RUN Enabled
Now running
Task completed in Parallel RUN...
[rambabu@Server01 ~]$ cat Prevent_cron-OR-Script_against_parallel_run.sh
#!/bin/bash
#Created by RambabuKella
#Date : 12-12-2013

#LOCK file name
Parallel_RUN="yes"
#Parallel_RUN="no"
PS_GREP=0
LOCK=/var/tmp/mylock_`whoami`_"$0"
#Checking for the process
PS_GREP=`ps -ef |grep "sh $0" |grep -v grep|wc -l`
if [ "$Parallel_RUN" == "no" ] ;then
echo "Parallel RUN Disabled"

 if [ -f $LOCK ] || [ $PS_GREP -gt 2 ] ;then
 echo -e "nJob is already running OR LOCK file exists. "
 echo -e "nDetail are : "
 ps -ef |grep "$0" |grep -v grep
 cat "$LOCK"
 exit 6
 fi
echo -e "LOCK file " $LOCK " created on : `date +%F-%H-%M` ." &> $LOCK
# do some work
echo "Now running"
echo "Task completed on with single RUN ..."
#done

rm -v $LOCK 2>/dev/null
exit 0
else

echo "Parallel RUN Enabled"

# do some work
echo "Now running"
echo "Task completed in Parallel RUN..."
#done

exit 0
fi
echo "some thing wrong"
exit 2
[rambabu@Server01 ~]$

I offer the following solution, in a script named 'flocktest'

#!/bin/bash
export LOGFILE=`basename $0`.logfile
logit () 
echo "$1" >>$LOGFILE

PROGPATH=$0
(
flock -x -n 257
(($?)) && logit "'$PROGPATH' is already running!" && exit 0
logit "'$PROGPATH', proc($$): sleeping 30 seconds"
sleep 30
)257<$PROGPATH