42

What is the linux command to find if a process say aa.sh is running or not. ps command does not seem to work and it does not show the shell script names.

Please advise.

Manikandan Kannan
  • 8,684
  • 15
  • 44
  • 65

9 Answers9

51

Check this

ps aux | grep "aa.sh"
krizna
  • 1,535
  • 12
  • 13
  • 5
    This can give you some surprises, let me give you two examples at the same time. First: it will find "aaa.sh" as well, which can cause errors. Second: grep will find itself, which you have to deal with. Pgrep is the elegant solution. – user897079 Jan 21 '15 at 01:39
  • 3
    We can use a trick to prevent grep showing itself: `ps aux | grep "[a]a.sh"` – Vassilis Oct 19 '15 at 11:10
  • Sorry, but``pgrep`` is the way to go, this solution need @Vassilis trick to work properly – Gilles Quénot Dec 25 '20 at 18:59
42

The simplest and efficient solution is :

pgrep -fl aa.sh

or as a condition:

if pgrep -fl aa.sh &>/dev/null; then
    do...
fi

Check: http://www.explainshell.com/explain?cmd=pgrep+-fl+aa.sh

Gilles Quénot
  • 173,512
  • 41
  • 224
  • 223
  • 13
    if anyone was wondering what this does, [see it explained](http://www.explainshell.com/explain?cmd=pgrep+-fl+aa.sh) – tutuDajuju Feb 21 '14 at 19:26
  • 3
    @tutuDajuju: Helpful, thanks; slight tangent: it's worth drawing more explicit attention to the service you link to: http://explainshell.com can parse arbitrary Unix command lines and explain the specific options used, based on Ubuntu man pages. Here's the explicit URL explaining this answer: http://www.explainshell.com/explain?cmd=pgrep+-fl+aa.sh – mklement0 Feb 21 '14 at 20:10
  • 1
    If you're scripting, you can then follow this with `if [ $? = 0 ]` to determine if the process was found (pgrep returns 0) or not (pgrep returns 1). – otocan Apr 05 '22 at 08:24
13

Adding to the answers above -

To use in a script, use the following :-

result=`ps aux | grep -i "myscript.sh" | grep -v "grep" | wc -l`
if [ $result -ge 1 ]
   then
        echo "script is running"
   else
        echo "script is not running"
fi
NRJ
  • 1,064
  • 3
  • 15
  • 32
  • If i run `ps aux | grep -i "myscript.sh" | grep -v "grep" | wc -l` alone, output is 0. If I run it in my script, result is 2 and script exits. Any suggestions whats wrong? – Ahue Sep 20 '14 at 13:06
  • 1
    one is for the script and one is for the grep itself. if you try `ps aux | grep hello` in a terminal, you will see the grep as a process. To prevent grep showing itself I use a trick: `ps aux | grep [h]ello` – Vassilis Oct 19 '15 at 11:17
5

The solutions above are great for interactive use, where you can eyeball the result and weed out false positives that way.

False positives can occur if the executable itself happens to match, or any arguments that are not script names match - the likelihood is greater with scripts that have no filename extensions.

Here's a more robust solution for scripting, using a shell function:

getscript() {
  pgrep -lf ".[ /]$1( |\$)"
}

Example use:

# List instance(s) of script "aa.sh" that are running.
getscript "aa.sh"  # -> (e.g.): 96112 bash /Users/jdoe/aa.sh

# Use in a test:
if getscript "aa.sh" >/dev/null; then
  echo RUNNING
fi
  • Matching is case-sensitive (on macOS, you could add -i to the pgrep call to make it case-insensitive; on Linux, that is not an option.)
  • The getscript function also works with full or partial paths that include the filename component; partial paths must not start with / and each component specified must be complete. The "fuller" the path specified, the lower the risk of false positives. Caveat: path matching will only work if the script was invoked with a path - this is generally true for scripts in the $PATH that are invoked directly.
  • Even this function cannot rule out all false positives, as paths can have embedded spaces, yet neither ps nor pgrep reflect the original quoting applied to the command line. All the function guarantees is that any match is not the first token (which is the interpreter), and that it occurs as a separate word, optionally preceded by a path.
  • Another approach to minimizing the risk of false positives could be to match the executable name (i.e., interpreter, such as bash) as well - assuming it is known; e.g.
# List instance(s) of a running *bash* script.
getbashscript() {
  pgrep -lf "(^|/)bash( | .*/)$1( |\$)"
}

If you're willing to make further assumptions - such as script-interpreter paths never containing embedded spaces - the regexes could be made more restrictive and thus further reduce the risk of false positives.

mklement0
  • 382,024
  • 64
  • 607
  • 775
5

Check this

ps -ef | grep shellscripname.sh

You can also find your running process in

ps -ef
Saurabh Lende
  • 953
  • 2
  • 13
  • 19
2
pgrep -f aa.sh 

To do something with the id, you pipe it. Here I kill all its child tasks.

pgrep aa.sh | xargs pgrep -P ${} | xargs kill

If you want to execute a command if the process is running do this

pgrep aa.sh && echo Running
2

I was quite inspired by the last answer by mklement0 - I have few scripts/small programs I run at every reboot via /etc/crontab. I built on his answer and built a login script, which shows if my programs are still running. I execute this scripts.sh via .profile -file on every login, to get instant notification on each login.

cat scripts.sh 
#!/bin/bash

getscript() {
  pgrep -lf ".[ /]$1( |\$)"
}

script1=keepalive.sh
script2=logger_v3.py

# test if script 1 is running
if getscript "$script1" >/dev/null; then
  echo "$script1" is RUNNING
  else
    echo "$script1" is NOT running
fi

# test if script 2 is running:
if getscript "$script2" >/dev/null; then
  echo "$script2" is RUNNING
  else
    echo "$script2" is NOT running
fi
rj45
  • 21
  • 3
1

here a quick script to test if a shell script is running

#!/bin/sh

scripToTest="your_script_here.sh"
scriptExist=$(pgrep -f "$scripToTest")
[ -z "$scriptExist" ] && echo "$scripToTest : not running" || echo "$scripToTest : runnning"
JaySync
  • 21
  • 5
0

Give an option to ps to display all the processes, an example is:

ps -A | grep "myshellscript.sh"

Check http://www.cyberciti.biz/faq/show-all-running-processes-in-linux/ for more info

And as Basile Starynkevitch mentioned in the comment pgrep is another solution.

lc2817
  • 3,722
  • 16
  • 40