Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Is there a script or a way in linux that when I try to execute a shell script/process, if the same is running, it will prompt that same is running and will exit otherwise it will continue.

share|improve this question
add comment

4 Answers 4

You can use this one liner to do what you want:

$ pgrep script.bash && echo "already running" || ( ./script.bash & )

Example

Say I had this script:

$ cat script.bash 
#!/bin/bash

echo "Hello World"
sleep 10

If we use our one liner:

$ pgrep script.bash && echo "already running" || ( ./script.bash & )
Hello World
$

We run it again:

$ pgrep script.bash && echo "already running" || ( ./script.bash & )
10197
already running
$

Waiting 10 seconds and running it again, it again works:

$ pgrep script.bash && echo "already running" || ( ./script.bash & )
Hello World
$
share|improve this answer
    
Also, the name of the bash script is it's unique identifier. So if the script file is renamed the above method wont work. Duh? –  Bleeding Fingers Mar 1 at 16:54
    
That should be obvious, I thought???? –  slm Mar 1 at 18:45
    
Well, to me and you, yes it is. But I left this comment for the novice users. –  Bleeding Fingers Mar 1 at 19:40
    
@BleedingFingers - Ha. That makes more sense...nevermind 8-) –  slm Mar 1 at 19:41
add comment

Note this answer is orientated toward a self checking script, for manually checking if a process is running before attempting to run it from the command line, see slm's answer.

The easiest way is to use pgrep if it is available:

if pgrep "$0" >/dev/null
then
  echo "$0 is already running" 2>&1
  exit 1
fi

If not, you can use a combination of ps and grep:

if ps -Ao comm | grep -q "^$0\$"
then
  echo "$0 is already running" 2>&1
  exit 1
fi

It is more robust to use a lock file though as it is always possible that the process is running under a different name. Here is an example using flock:

lockfile=/var/lock/mprog
{
  if ! flock -n 9
  then
    echo "Unable to lock $lockfile, exiting" 2>&1
    exit 1
  fi

  # do stuff here

} 9>"$lockfile"
share|improve this answer
1  
The file locking approach is much better than any of the other approaches posted, since it avoids a race condition. The others do not. –  Nate Eldredge Mar 1 at 21:43
add comment

There are many ways to do that. I prefer that the script prevents from running same copies by itself by storing it's pid.

One convenient method is pidof

$ pidof -x /bin/yourscript || /bin/yourscript  

with ps

$ ps aux|grep -q /bin/yourscript || /bin/yourscript

self checking

#!/bin/sh

NAME=$(basename $0)

if ps -p `cat /var/run/$NAME".pid` >/dev/null 2>&1; then
   echo "script already running"
   exit 1
fi

echo $$ > /var/run/$NAME".pid"

...
rm /var/run/$NAME".pid"

there are a lot of other scripts. For example solo

share|improve this answer
1  
Only problem with the pid file approach is that if the script finishes prematurely (eg is killed) and can't delete the file, there is always the chance that a completely different process will have the stored pid next time the script runs. –  Graeme Mar 1 at 13:19
    
Right. Therefore this is only the light version. :-) However there are still a lot of scripts they do not check even this and stop only if the pidfile exists. –  bersch Mar 1 at 17:25
    
Yeah, I'm not sure how portable the various lock file approaches are. In some cases this may be the best option. –  Graeme Mar 1 at 17:31
    
@Graeme: Wise spoken. –  bersch Mar 1 at 18:10
    
All of these approaches have a race condition. –  Nate Eldredge Mar 1 at 21:42
add comment

The fact that doing something like this reliably in Unix in general is impossible was one of the things that sparked off the development of tools like systemd (it uses the Linux-specific cgroups feature to cage processes, and thus keeping them under tight control, including restarting as needed). You can cobble something together using ps(1) or pgrep(1), stashing away a PID in a file and checking, and so on. But all of those are subject to races, cheating, or plain mistakes.

You should go over your needs and see how critical it is if it goes awry, how repetitive this is (is it worth automating, or is it something done on and off?), how interesting a target it is for potential attackers, and so on.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.