to check instance of a script running
Hi,
I have a script called check.sh which does a bunch of things and generally takes 5-10 mins to process.I run it from the /root/check.sh location. Now I would like to know how can I prevent it to run when it is already running. In short how can I make sure that the user does not run the second instance(by mistake) of that script while it is already running. How can I check this in the check.sh script itself? What lines will I have to write at the beginning of the script to achieve this. Thanks |
you could create a lock file. crude but works? or where u thinking of somehting more technical?
|
Quote:
thanks for the effort though... |
I'm not entirely sure, but putting this code at the beginning of check.sh should do the trick:
Code:
#! /bin/bash |
Quote:
Thanks baldwonder. I will try that and see how it goes. Thank you very much. |
good idea, but even if there are no processes running "wc" reports one line.
try "ps -ef|grep -i sopnfgsdpajgsn |wc -l" and you will see what i mean. so you might need to use: if test $test -gt 1 then exit 2 fi this is because grep finds itself. you could also do: ps -ef|grep check.sh|grep -v grep|wc -l or similar... |
One possible simple locking method for scripts:
Code:
kill -0 `cat /var/lock/yourscript 2> /dev/null` 2> /dev/null && exit 1 |
Quote:
I use the lock file method. This is handy if you are running the script as a daemon; to terminate the daemon, design the script to stop if the lock file disappears, then design a kill script to remove the lock file. This is a much easier and safer way to terminate as opposed to finding the process number and killing it. Here is an example: scroll down and look for the secure message interface example (mostly the 'receive' and 'kill' scripts.) ta0kira |
i like the kill -0 option.
there will be 2 from within the script. 1 - the script itself 2 grep finding itself greppingg. so you would have to put gt 2. sorry i didnt think of that. the kill way is more elegant. |
Quote:
'kill 0' works fine if you are calling it from the same shell it was started in; what if it starts without a tty like in an rc, or if the process extends beyond the shell it was called in? I kind of think kill is a little sloppy anyway; it doesn't give the script a chance to exit its own way, kind of like turning off your power strip instead of shutting down your computer properly. I think it's meant to clean up messes left by processes that encounter something they can't work around and they end up hanging (and for real binaries which are designed to process a TERM signal.) Also, if you are writing or reading a fifo, you could hang another entirely separate process that's trying to use the other end of it. ta0kira |
So I realized I used the wrong ps option in my code above. If you use ps -e instead of ps aux, it will show up as code.sh and not as grep (grep will be there, but only as grep and not grep check.sh). Satinet is right, you would have to change the code to say
[code] if [ $test -gt 1 ]; then exit 0 fi [\code] since there will be one instance of the code running when you are checking for extras. |
Quote:
I think you must be confusing kill -0 with kill 0? The latter sends SIGTERM (signal 15) to the process group. That won't work in this case. It needs a dash. Quote:
Furthermore, the only signal that doesn't allow programs to exit their own way is the forementioned SIGKILL (signal 9). All the other signals (including SIGTERM, 15 and SIGINT, 2, which is same as CTRL+C) can be handled using the trap command, from scripts as well as binaries. Signal 0 of course doesn't need to be handled as it does nothing... Quote:
|
ps | grep isn't really resilient.
for instance it will find 'vi check.sh' It also seems faintly inelegant to me. pgrep -x check.sh may work better. I generally use a lock file myself. t seems a common idiom so maybe it works? |
i wrote a script like this on hp ux:
MYSTATUS="$(UNIX95= ps -C $PROC -o pid= -o comm=)" if [ -z "$MYSTATUS" ] then <do something> fi Although i doubt this would work on linux quite the same. anyway, this code avoids the whole grep issue. which is something to be mindful of on production/important servers/computers. grep can give results that you dont expect. e,g someone could run another check related programme at the same time, which could throw a spanner in the works. |
Quote:
Quote:
Quote:
Quote:
ta0kira |
All times are GMT -5. The time now is 11:59 PM. |