Bash script to check running process [duplicate]
I wrote a bash-script to check if a process is running. It doesn’t work since the ps command always returns exit code 1. When I run the ps command from the command-line, the $? is correctly set, but within the script it is always 1. Any idea?
#!/bin/bash SERVICE=$1 ps -a | grep -v grep | grep $1 > /dev/null result=$? echo "exit code: $" if [ "$" -eq "0" ] ; then echo "`date`: $SERVICE service running, everything is fine" else echo "`date`: $SERVICE is not running" fi Could you just check to see if you get non-empty output from the grep command instead of relying on return values?
I tried this and have a similar problem. The output is not taken into account. Here the code: #!/bin/bash SERVICE=$1 OUTPUT=$(ps -a | grep -v grep | grep $1) echo $OUTPUT if [ «$<#OUTPUT>» -gt 0 ] ; then echo » date : $SERVICE service running, everything is fine» else echo » date : $SERVICE is not running» fi
15 Answers 15
There are a few really simple methods:
pgrep procname && echo Running pgrep procname || echo Not running killall -q -0 procname && echo Running pidof procname && echo Running Your method will return a result even if a process just contains the process name you’re looking for. It’s not a solution to check with exact name.
This trick works for me. Hope this could help you. Let’s save the followings as checkRunningProcess.sh
#!/bin/bash ps_out=`ps -ef | grep $1 | grep -v 'grep' | grep -v $0` result=$(echo $ps_out | grep "$1") if [[ "$result" != "" ]];then echo "Running" else echo "Not Running" fi Make the checkRunningProcess.sh executable.And then use it.
Example to use.
20:10 $ checkRunningProcess.sh proxy.py Running 20:12 $ checkRunningProcess.sh abcdef Not Running this is what I needed to check if process running by it’s command line arguments as well. what is the difference ps aux vs ps -ef
I tried your version on BASH version 3.2.29, worked fine. However, you could do something like the above suggested, an example here:
#!/bin/sh SERVICE="$1" RESULT=`ps -ef | grep $1 | grep -v 'grep' | grep -v $0` result=$(echo $ps_out | grep "$1") if [[ "$result" != "" ]];then echo "Running" else echo "Not Running" fi I tried it out, doesn’t work neither. There must be something fishy with my environment (a shared hosting provider).
nothing special: the output is + SERVICE=rails + ps -a + grep -v grep + grep rails + result=1 + echo ‘exit code: 1’ exit code: 1 + ‘[‘ 1 -eq 0 ‘]’ ++ date + echo ‘Tue May 25 06:52:25 EDT 2010: rails is not running’
Just a heads up: ps -a only lists processes of the user in the current terminal. However, ps -A checks for ALL PROCESSES.
I use this one to check every 10 seconds process is running and start if not and allows multiple arguments:
#!/bin/sh PROCESS="$1" PROCANDARGS=$* while : do RESULT=`pgrep $` if [ "$" = null ]; then echo "$ not running, starting "$PROCANDARGS $PROCANDARGS & else echo "running" fi sleep 10 done Check if your scripts name doesn’t contain $SERVICE. If it does, it will be shown in ps results, causing script to always think that service is running. You can grep it against current filename like this:
#!/bin/sh SERVICE=$1 if ps ax | grep -v grep | grep -v $0 | grep $SERVICE > /dev/null then echo "$SERVICE service running, everything is fine" else echo "$SERVICE is not running" fi for those that want to use this as part of a script, and not as a function, change $0 to grep ps ax | grep -v grep | grep -v grep | grep $SERVICE > /dev/null
!/bin/bash CHECK=$0 SERVICE=$1 DATE=`date` OUTPUT=$(ps aux | grep -v grep | grep -v $CHECK |grep $1) echo $OUTPUT if [ "$" -gt 0 ] ; then echo "$DATE: $SERVICE service running, everything is fine" else echo "$DATE: $SERVICE is not running" fi
pgrep is a better solution, you still have the problem that you do not check the process name but the whole output of ps aux.
Despite some success with the /dev/null approach in bash. When I pushed the solution to cron it failed. Checking the size of a returned command worked perfectly though. The ampersrand allows bash to exit.
#!/bin/bash SERVICE=/path/to/my/service result=$(ps ax|grep -v grep|grep $SERVICE) echo $ if $> 0 then echo " Working!" else echo "Not Working. Restarting" /usr/bin/xvfb-run -a /opt/python27/bin/python2.7 SERVICE & fi #!/bin/bash ps axho comm| grep $1 > /dev/null result=$? echo "exit code: $" if [ "$" -eq "0" ] ; then echo "`date`: $SERVICE service running, everything is fine" else echo "`date`: $SERVICE is not running" /etc/init.d/$1 restart fi
Those are helpful hints. I just needed to know if a service was running when I started the script, so I could leave the service in the same state when I left. I ended up using this:
HTTPDSERVICE=$(ps -A | grep httpd | head -1) [ -z "$HTTPDSERVICE" ] && echo "No apache service running." I found the problem. ps -ae instead ps -a works.
I guess it has to do with my rights in the shared hosting environment. There’s apparently a difference between executing «ps -a» from the command line and executing it from within a bash-script.
A simple script version of one of Andor’s above suggestions:
!/bin/bash pgrep $1 && echo Running If the above script is called test.sh then, in order to test, type: test.sh NameOfProcessToCheck
I was wondering if it would be a good idea to have progressive attempts at a process, so you pass this func a process name func_terminate_process «firefox» and it tires things more nicely first, then moves on to kill.
# -- NICE: try to use killall to stop process(s) killall $ > /dev/null 2>&1 ;sleep 10 # -- if we do not see the process, just end the function pgrep $ > /dev/null 2>&1 || return # -- UGLY: Step trough every pid and use kill -9 on them individually for PID in $(pidof $) ;do echo "Terminating Process: [$], PID [$]" kill -9 $ ;sleep 10 # -- NASTY: If kill -9 fails, try SIGTERM on PID if ps -p $ > /dev/null ;then echo "$ is still running, forcefully terminating with SIGTERM" kill -SIGTERM $ ;sleep 10 fi done # -- If after all that, we still see the process, report that to the screen. pgrep $ > /dev/null 2>&1 && echo "Error, unable to terminate all or any of [$]" || echo "Terminate process [$] : SUCCESSFUL" I need to do this from time to time and end up hacking the command line until it works.
For example, here I want to see if I have any SSH connections, (the 8th column returned by «ps» is the running «path-to-procname» and is filtered by «awk»:
ps | awk -e '< print $8 >' | grep ssh | sed -e 's/.*\///g' Then I put it in a shell-script, («eval»-ing the command line inside of backticks), like this:
#!/bin/bash VNC_STRING=`ps | awk -e '< print $8 >' | grep vnc | sed -e 's/.*\///g'` if [ ! -z "$VNC_STRING" ]; then echo "The VNC STRING is not empty, therefore your process is running." fi The «sed» part trims the path to the exact token and might not be necessary for your needs.
Here’s my example I used to get your answer. I wrote it to automatically create 2 SSH tunnels and launch a VNC client for each.
I run it from my Cygwin shell to do admin to my backend from my windows workstation, so I can jump to UNIX/LINUX-land with one command, (this also assumes the client rsa keys have already been «ssh-copy-id»-ed and are known to the remote host).
It’s idempotent in that each proc/command only fires when their $VAR eval’s to an empty string.
It appends » | wc -l» to store the number of running procs that match, (i.e., number of lines found), instead of proc-name for each $VAR to suit my needs. I keep the «echo» statements so I can re-run and diagnose the state of both connections.
#!/bin/bash SSH_COUNT=`eval ps | awk -e '< print $8 >' | grep ssh | sed -e 's/.*\///g' | wc -l` VNC_COUNT=`eval ps | awk -e '< print $8 >' | grep vnc | sed -e 's/.*\///g' | wc -l` if [ $SSH_COUNT = "2" ]; then echo "There are already 2 SSH tunnels." elif [ $SSH_COUNT = "1" ]; then echo "There is only 1 SSH tunnel." elif [ $SSH_COUNT = "0" ]; then echo "connecting 2 SSH tunnels." ssh -L 5901:localhost:5901 -f -l USER1 HOST1 sleep 10; ssh -L 5904:localhost:5904 -f -l USER2 HOST2 sleep 10; fi if [ $VNC_COUNT = "2" ]; then echo "There are already 2 VNC sessions." elif [ $VNC_COUNT = "1" ]; then echo "There is only 1 VNC session." elif [ $VNC_COUNT = "0" ]; then echo "launching 2 vnc sessions." vncviewer.exe localhost:1 & vncviewer.exe localhost:4 & fi This is very perl-like to me and possibly more unix utils than true shell scripting. I know there are lots of «MAGIC» numbers and cheezy hard-coded values but it works, (I think I’m also in poor taste for using so much UPPERCASE too). Flexibility can be added with some cmd-line args to make this more versatile but I wanted to share what worked for me. Please improve and share. Cheers.
Linux command to check if a shell script is running or not
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.
9 Answers 9
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.
The simplest and efficient solution is :
if pgrep -fl aa.sh &>/dev/null; then do. fi @tutuDajuju: Helpful, thanks; slight tangent: it’s worth drawing more explicit attention to the service you link to: 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: explainshell.com/explain?cmd=pgrep+-fl+aa.sh
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).
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 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?
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
ps -ef | grep shellscripname.sh You can also find your running process in
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:
# 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.