ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

I want to programmatically detect if a certain PHP script is running in a BASH script. If it is not running, then I run it again. So something like...

  if script is not running
    run the script

I can run "ps aux | grep thescriptname.php" and it will show the script in the output. It will also output the call to grep, which I guess, is like a false positive. Even without that false positive, I'm not sure how I'd use the results of the grep in my "if" statement.

It's not good to just check if the PHP executable is running, because it runs other scripts. I specifically need to know if this one script is being ran by the PHP executable.

So how do I write something in BASH that will tell me if the script is running or not? There ought to be some simple way to do it that I'm ignorant of.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

if ps -C scriptname 1>&- 2>&-;
then scriptname;
fi;

EDIT: Wait, I got it backwards. I forget whether bash has an easy not command. You could always do

if ps -C scriptname 1>&- 2>&-;
then :;
else script;
fi;

---

[Last edited by coppro at 10-15-2007 03:15 AM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

I appreciate the reply, but that doesn't really work. Keep in mind that the command line to launch the PHP script is...

php TheScript.php

So I can run "ps -C php" to detect PHP, but I can't run "ps -C TheScript.php" to detect the specific script that is running. At any given time, the PHP executable might be running multiple PHP scripts, some of which I don't care about.

My current solution is to write a temporary lock file inside of TheScript.php to indicate when it is running, but this isn't very robust. I would rather check directly for whether or not TheScript.php is running.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

Just add "o args" to the command line (no dashes!) and it will output the full command line. So, you can do:

if ps -C php -o args | grep ScriptName.php 1>&- 2>&-;
then :;
else script;
fi;

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

not the most elegant way to do it, perhaps, but probably functional (at least on my limited tests against another process on the system, and replacing "php FooScript.php" with "echo "not found"") - notice the "grep -v grep" to eliminate false positives.

#!/bin/bash

S=`ps auwwx | grep 'php FooScript.php' | grep -v grep`

if [ "$S" == "" ]; then
    php FooScript.php
fi

though, in my experience, the usual method used by linux daemons is to write a pid file and do operations on the value in that file.


____________________________

---

[Last edited by silver at 10-15-2007 04:23 AM]

schep
Level: Smitemaster

Rank Points: 865
Registered: 03-01-2005
IP: Logged

One possibly useful trick I sometimes use:
ps | grep '[S]omeString'

The brackets don't change the meaning of the regular expression, so it searches for 'SomeString'. But since ps reports the grep command with the brackets, grep won't match its own process.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Schik gave me something that worked which is a variant of silver's solution. Much thanks for the help, guys.

-Erik


____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

I'm curious what Schik's variant is. I may find it enlightening.


____________________________

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Okay, silver, here you have it. For security reasons, a few things are obfuscated.

#!/bin/tcsh -f
set x=`ps -ef | grep "/usr/bin/php /somepath/TheScript.php" | grep -v grep | wc -l`
if ($x == 0) then
  /usr/bin/php /somepath/TheScript.php
endif

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

I know I'm late into this discussion, but the canonical way of doing something like this is running the script, then writing it's process ID into a file in /var/run/thescript.pid (and setting up a handler to delete the PID file when the script terminates).

Then whenever you need to check if the script is still running you can either check for the existence of the PID file, or you can read it's content and check for the existence of a process with this exact PID that's running your command.

When you run a script in the background with "&" bash will store the PID in the "$!" variable, so you can use it to write your PID file from your bash script if you want.

Now, to check if that process is still running (I've been using "sleep" as a test subject here) simply use

[[ $(ps -p $! -o comm --no-headers) == "sleep" ]]

in an if-statement, which will compare the name of the executable run by the last started process to "sleep". Feel free to replace "$!" with another variable holding the PID from the file...

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

---

[Last edited by Briareos at 10-15-2007 09:01 AM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

I'm not changing what I have because I spent enough time on it and it works. But set aside my particular problem for a bit.

I know I'm late into this discussion, but the canonical way of doing something like this is running the script, then writing it's process ID into a file in /var/run/thescript.pid (and setting up a handler to delete the PID file when the script terminates).

Why should that be the canonical way? I'm not saying it isn't the canonical way, but why? It relies on application behavior to learn something that the O/S should already expose. If I were writing against O/S APIs, (i.e. POSIX libraries, I guess) instead of hacking around with my scripts and PHPs, wouldn't I use code to retrieve information about processes directly? Like for example, whoever wrote the "ps" program used some kind of O/S API to enumerate the processes, right? It seems kludgy to rely on reading application-written files to figure this stuff out.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

Briareos agreed with me "though in my experience, the usual method used by linux daemons is to write a pid file and do operations on the value in that file"

as for why it is so... hrm. I don't actually know, but if I had to guess, then at some point in the early days of *n*x, process table examination was one or more of: difficult, slow, error prone, misleading, insecure, obscure, OS-dependent, and/or language-dependent. rather than fix whatever issue or issues there were, they made a "standard" of putting daemon pids in /var/run. just a guess. it's probably an interesting historical question about the evolution of *n*x OS.

another interesting question: do you write "Operating/System" or "Operating System". if the latter, why do you abbreviate it with a slash?

anyway: I can think of 7 things which might be related to the reason, or might be the reason, or might just be side notes:

1) a program can (or used to be able to) blatantly lie on the process table by injecting any string it desires into argv[0]. say I maliciously want to prevent sendmail from starting as a daemon. if know that it checks the process table for "sendmail -d" (or whatever), I could start up a program which makes the same name appear (and then sleep(5000)s or something) without having to have secured access to /var/run/sendmail.pid

2) say instead of having a separate bash script as the nanny, like you did, I wrote self-nannying behavior into my code: i.e. on startup I look for a program named the same thing as me with my startup options already running... then I don't start if I find a pid file and find that pid exists. this is probably "normal" for C daemons, in fact - that way you can just cron "startItUp -d" every 5 minutes and rely on it never starting itself more than once... except if I'm examining the process table for "startItUp -d", I myself am already listed there!

3) a daemon like apache forks copies of itself, but only the parent pid is kept in /var/run

4) "perfectly normal operations" for a daemon might include having a root copy which writes a pid to /var/run, and user copies which write pids /home/$USERNAME/var/run or somesuch.

5) a daemon might not be a single program at all, but a chain of programs - grepping ps (or writing equivalent direct API calls) might be difficult under such circumstances since there might be half a dozen strings to look for instead of one.

6) " kill -1 `cat /var/run/sendmail.pid` " is easier to type than " kill -1 `some long ps/grep command to find the pid of sendmail` "

7) it might be "normal" for my daemon to "wrap up the part that matters" and remove the .pid file long before it's done running - like if it mails the results of the last operation out.

all these ideas have flaws and workarounds, of course (especially with some more tools, like a kill that takes process names instead of PIDs as arguments), so this might just be useless information.


____________________________

---

[Last edited by silver at 10-15-2007 10:53 AM]

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

ErikH2000 wrote:
Why should that be the canonical way? I'm not saying it isn't the canonical way, but why?

Well, it's what's used by all Linux distros I have experience with for running their daemons, so I based my calling it canon on that.

It also allows one to find out that the previously running instance has terminated unexpectedly when there's still a PID file around but the process it is referencing is dead.

Also, simply keeping a file write lock on the PID file allows easy prevention of a daemon process being started twice - if the file can't be written, there's already an instance running (or your file permissions for it are screwed, but that's easily fixed).

Come to think of it - if you keep a file write lock on the PID file while your script is running detecting whether the process is still there boils down to whether the file can be opened in write mode or not...

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

---

[Last edited by Briareos at 10-15-2007 10:58 AM]

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

but ew. who likes to decipher the args to flock()?

(and thanks for providing reason-possibilities 8 and 9)


____________________________

---

[Last edited by silver at 10-15-2007 10:59 AM]

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

silver wrote:
but ew. who likes to decipher the args to flock()?

What, the file descriptor and one of the three possible mode values?

But after reading TFM I'm not so sure you can lock a file just against writing using normal file locking semantics in Linux...

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

well, like most sane people, I prefer fopen() to fdopen() because of the nicer subsequent command semantics. so the fd isn't always so neatly available to me.

anyway, I was actually thinking of the older, more fun, locking with fcntl(), my bad. in fact, I never really know whether I'm "supposed" to be using flock(), fcntl(), or lockf(). I hate that whole branch of the kernel.



____________________________

---

[Last edited by silver at 10-15-2007 11:08 AM]

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

silver wrote:
well, like most sane people, I prefer fopen() to fdopen() because of the nicer subsequent command semantics. so the fd isn't always so neatly available to me.

You mean open (fdopen gives you a FILE*, like fopen)? I like open!



Anyways, you can use fileno(fp) to get the fd for any FILE*.

anyway, I was actually thinking of the older, more fun, locking with fcntl(), my bad. in fact, I never really know whether I'm "supposed" to be using flock(), fcntl(), or lockf(). I hate that whole branch of the kernel.

Yeah, there's differences in how they work, if they work over nfs and such, if the lock is mandatory or just advisory (usually the latter, also depends on the mount), etc. DROD just uses an atomic link in stead of all that stuff.

---

[Last edited by trick at 10-15-2007 06:57 PM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

silver wrote:
another interesting question: do you write "Operating/System" or "Operating System". if the latter, why do you abbreviate it with a slash?

Jeezus, I have no idea. I picked it up someplace, I guess. Makes absolutely no sense to me. Maybe I will stop doing it. You can Google "O/S" and see that at least I'm not alone.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

mrimer
Level: Legendary Smitemaster

Rank Points: 5058
Registered: 02-04-2003
IP: Logged

Interesting. I'll put on my academic hat for a second. The other O/Ss I see in searches are part of proper names of actual operating systems, and not exactly an abbreviation of "operating system". Maybe it all started with PS/1, PS/2, and then OS/2, and then people decided by popular precedent that OS needed a slash next to it somewhere, even when no suffix was present.

Heh heh...

Linux: A -REAL- O/S


____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

Actually, I'd think it's more descriptive of Windows: You either get a system, or it operates.

*ducks*

Briareos
Level: Smitemaster

Rank Points: 3516
Registered: 08-07-2005
IP: Logged

Are there any constraints to the value of S in that equation?

____________________________
"I'm not anti-anything, I'm anti-everything, it fits better." - Sole
R.I.P. Robert Feldhoff (1962-2009)

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

On an unrelated note, I remember finding a utility (from GNU, AFAIK) that searches a binary for readable text strings and outputs them, but subsequently forgetting. Can anyone remind me which one that is?

Schik
Level: Legendary Smitemaster

Rank Points: 5383
Registered: 02-04-2003
IP: Logged

coppro wrote:
On an unrelated note, I remember finding a utility (from GNU, AFAIK) that searches a binary for readable text strings and outputs them, but subsequently forgetting. Can anyone remind me which one that is?

That would be called "strings", oddly enough

____________________________
The greatness of a nation and its moral progress can be judged by the way it treats its animals.
--Mahatma Gandhi

silver
Level: Smitemaster
Rank Points: 915
Registered: 01-18-2005
IP: Logged

it's called... strings
ta da.

edit: dang simultaneous posts.

____________________________

---

[Last edited by silver at 10-16-2007 07:19 AM]

coppro
Level: Smitemaster
Rank Points: 1308
Registered: 11-24-2005
IP: Logged

There we go.
Thanks. It's impossible to apropos that one, as you might suspect.