GetPid("ApplicationName"); or, how do I autokill a process w/o knowing its PID#?

AHunter3 · 05-12-2003, 03:13 PM

I need to set up a routine that will kill and restart a Carbon application that tends to hang. Doing something akin to this in the Terminal:

Quote:


	osascript -e 'tell application "ApplicationName" to quit'

...doesn't work because the application is hung.

If I were doing it in person, I could get the PID from "top" and then issue the "kill #" command, but since the PID is going to be different and of unpredictable value, I don't see any easy way of using that.

Unless there exists an easily accessed routine for obtaining the current PID for an application if you happen to know its name?

Alternatively, is there an osa command that will kill off a hung application, as opposed to telling the application to kindly absent itself?

The application, btw, is FileMaker Pro, and the "hung" condition consists of a modal message box coming up on screen stating that "Communication with the Host has been interrupted and cannot be reestablished" with an "OK" button. With that message box up, FileMaker is unresponsive to anything and everything, short of someone reaching over with the mouse and clicking the blasted button.

Hmm, that's another possibility. Is there an OS X version of "Okey Dokey", a "pusher of default dialog buttons on unattended computers" kind of utility?

jbc · 05-12-2003, 04:30 PM

I'm new to shell scripting, but I found the following technique for getting the pid and killing a process works fine for me. I use it in my "ip-up" script for restarting Meteorologist so it will update immediately when I start my dial-up connection. Something similar might work for you. You also might check "man kill"; not sure if the default signal is the best for dealing with a hung application or not.

Code:

#!/bin/sh

METEO=`ps wwax | egrep -i "[m]eteorologist" | awk '{ print $1 }'`

if [ $METEO ]
then
	kill $METEO
fi

open -a Meteorologist

Brad

mervTormel · 05-12-2003, 04:58 PM

yep. brad's got the drop on it.

what you want is to be real darn sure that the process name string you grep is unique for all
instances of your process table, since kill will gladly blow the head off of multiple PIDs...

Code:

$ ps wwax | egrep -i '/[p]th'
  531  ??  S     25:05.07 /Volumes/chunder/xapps/PTHClock/PTHClock.app/Contents/MacOS/PTHClock -psn_0_1572865
  552  ??  S      1:24.11 /Volumes/chunder/xapps/PTHPasteboard/PTHPasteboard.app/Contents/MacOS/PTHPasteboard -psn_0_2621441
 3326  ??  S      3:38.36 /Volumes/ebola/xdowns-n-z/PTHiTunesNotifier/PTHiTunesNotifier.app/Contents/MacOS/PTHiTunesNotifier -psn_0_39714817

$ ps wwax | egrep -i '/[p]thclock '
  531  ??  S     25:05.13 /Volumes/chunder/xapps/PTHClock/PTHClock.app/Contents/MacOS/PTHClock -psn_0_1572865

at_sym · 05-12-2003, 05:48 PM

Just out of curiosity, why do you need to include the first character of the search string in square brackets?

Based on the grep manpage, that will match any single character in the list. Is that just a way of speeding up the search? (If the first character of the process isn't an M, don't bother processing it.)

jbc · 05-12-2003, 06:00 PM

I was baffled by this also. As I recall, without the square brackets, the grep line itself also gets returned with the result, although I'm not sure why. Have to consult merv about that one.

Btw, I originally kludged my script together based on two *brilliant* ideas posted my mervTormel and pmccann.

Credit where credit is due...

mervTormel · 05-12-2003, 06:02 PM

it's a grep trick.

the regexp "[s]tring" isn't found in the grep process ps listing

it's a shortcut to prevent having to pipe the output thru "grep -v grep"

from O'Reilly's "Essential System Administration" by AEleen Frisch:

"...so that the ps line for the grep command itself will not be selected
(since the string "string" does not appear in it)..."

Code:

$ ps wwax | egrep -i '[p]thclock|grep'
  531  ??  S     25:32.84 /Volumes/chunder/xapps/PTHClock/PTHClock.app/Contents/MacOS/PTHClock -psn_0_1572865
11902 std  U+     0:00.00 egrep -i [p]thclock|grep

jbc · 05-12-2003, 06:53 PM

Thanks for clarifying that, merv. Makes perfect sense now. One more thing I can use and actually know *why* I'm using it! Which is always a plus when writing shell scripts.

mervTormel · 05-12-2003, 07:10 PM

Quote:


	Originally posted by jbc Thanks for clarifying that, merv. Makes perfect sense now...

really? i still have to pause for a long, pregnant term to get my head around it.

if you study regular expressions a bit, it becomes less allusive.

the regexp bracket notation [] is a range, and can be a single char. so, in our example, it is a single char that has to be there to match. the grep interprets this regexp and goes hunting (matching char by char). but, in the entry in the process table for the grep process itself, the literal chars '[s]tring' are there, ergo, it fails as it doesn't contain the 'string' pattern (an absolute ess char, followed by 'tring') we are trying to match.

urk. my brain now pattern matches a swill bucket.

yer welcome.

gatorparrots · 05-12-2003, 07:18 PM

To avoid the grep trick, use this syntax:
ps axc | grep Meteorologist

jbc · 05-12-2003, 07:26 PM

Hehe...I said it makes perfect sense now. I didn't mean to imply it didn't take banging my head against the wall a few times!

Once I get it into my head that the grep process of searching for a process is itself a process that gets searched by the grep process, I'm okay with the rest of the logic.

Yep. Two wrongs don't make a right, but three lefts do...basic Unix rule of thumb. Thanks again.

Brad

mervTormel · 05-12-2003, 07:31 PM

aye. but, it will fail for CFM apps and commands not unique within 16 characters. so, best to be thorough and unique when entrusting your tender bits to the kill command...

$ ps axc | grep -i pth\|cfm
531 ?? S 26:10.73 PTHClock
542 ?? S 22:35.07 LaunchCFMApp
550 ?? S 12:26.65 LaunchCFMApp
552 ?? S 1:28.59 PTHPasteboard
553 ?? S 2:52.85 LaunchCFMApp
555 ?? S 68:53.66 LaunchCFMApp
3326 ?? S 4:28.92 PTHiTunesNotifie
8010 ?? S 3:34.01 LaunchCFMApp

AHunter3 · 05-12-2003, 11:40 PM

Thanks muchly!

I'm really going to have to sit down one of these days and learn "grep"...

WillyT · 05-13-2003, 03:38 AM

(if you only need it to stop)
At the end of my .xinitrc I use this:

Code:

kill -9 `ps -ax | grep enlightenment | grep -v grep | awk '{print $1}'`

I suppose the -c trick would work here too.

gatorparrots · 05-13-2003, 07:36 AM

The -c flag on ps eliminates the need for the | grep -v grep, which makes for a much more effecient string of commands.

XSage · 05-16-2003, 01:04 AM

Quite possibly the sloppiest solution imaginable is the killall command (/usr/bin/killall).

Usage:

Code:

killall <applicationname>

So if you wanted to kill the finder, you would do:

Code:

killall Finder

That easy. Look at "man killall" for details.

05-12-2003, 04:30 PM	#2
jbc All Star Join Date: Feb 2003 Location: Chico, CA Posts: 686	I'm new to shell scripting, but I found the following technique for getting the pid and killing a process works fine for me. I use it in my "ip-up" script for restarting Meteorologist so it will update immediately when I start my dial-up connection. Something similar might work for you. You also might check "man kill"; not sure if the default signal is the best for dealing with a hung application or not. Code: #!/bin/sh METEO=`ps wwax \| egrep -i "[m]eteorologist" \| awk '{ print $1 }'` if [ $METEO ] then kill $METEO fi open -a Meteorologist Brad

05-12-2003, 05:48 PM	#4
at_sym Triple-A Player Join Date: Jan 2002 Posts: 179	Small hijack... Just out of curiosity, why do you need to include the first character of the search string in square brackets? Based on the grep manpage, that will match any single character in the list. Is that just a way of speeding up the search? (If the first character of the process isn't an M, don't bother processing it.)

05-12-2003, 06:02 PM	#6
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	it's a grep trick. the regexp "[s]tring" isn't found in the grep process ps listing it's a shortcut to prevent having to pipe the output thru "grep -v grep" from O'Reilly's "Essential System Administration" by AEleen Frisch: "...so that the ps line for the grep command itself will not be selected (since the string "string" does not appear in it)..." Code: $ ps wwax \| egrep -i '[p]thclock\|grep' 531 ?? S 25:32.84 /Volumes/chunder/xapps/PTHClock/PTHClock.app/Contents/MacOS/PTHClock -psn_0_1572865 11902 std U+ 0:00.00 egrep -i [p]thclock\|grep __________________ On a clear disk, you can seek forever.

05-12-2003, 07:31 PM	#11
mervTormel League Commissioner Join Date: Jan 2002 Posts: 5,536	aye. but, it will fail for CFM apps and commands not unique within 16 characters. so, best to be thorough and unique when entrusting your tender bits to the kill command... $ ps axc \| grep -i pth\\|cfm 531 ?? S 26:10.73 PTHClock 542 ?? S 22:35.07 LaunchCFMApp 550 ?? S 12:26.65 LaunchCFMApp 552 ?? S 1:28.59 PTHPasteboard 553 ?? S 2:52.85 LaunchCFMApp 555 ?? S 68:53.66 LaunchCFMApp 3326 ?? S 4:28.92 PTHiTunesNotifie 8010 ?? S 3:34.01 LaunchCFMApp __________________ On a clear disk, you can seek forever.

05-13-2003, 03:38 AM	#13
WillyT Major Leaguer Join Date: Jan 2002 Location: Midwest Not quite Normal Posts: 416	One liner (if you only need it to stop) At the end of my .xinitrc I use this: Code: kill -9 `ps -ax \| grep enlightenment \| grep -v grep \| awk '{print $1}'` I suppose the -c trick would work here too. __________________ I have a Reason3 not to be grumpy and now I have a Rosegarden that works. Willy Last edited by WillyT; 05-13-2003 at 03:46 AM.

05-12-2003, 06:00 PM	#5
jbc All Star Join Date: Feb 2003 Location: Chico, CA Posts: 686	I was baffled by this also. As I recall, without the square brackets, the grep line itself also gets returned with the result, although I'm not sure why. Have to consult merv about that one. Btw, I originally kludged my script together based on two brilliant ideas posted my mervTormel and pmccann. Credit where credit is due...

05-12-2003, 06:53 PM	#7
jbc All Star Join Date: Feb 2003 Location: Chico, CA Posts: 686	Thanks for clarifying that, merv. Makes perfect sense now. One more thing I can use and actually know why I'm using it! Which is always a plus when writing shell scripts.

05-12-2003, 07:18 PM	#9
gatorparrots Major Leaguer Join Date: Dec 2002 Posts: 441	To avoid the grep trick, use this syntax: ps axc \| grep Meteorologist

05-12-2003, 07:26 PM	#10
jbc All Star Join Date: Feb 2003 Location: Chico, CA Posts: 686	Hehe...I said it makes perfect sense now. I didn't mean to imply it didn't take banging my head against the wall a few times! Once I get it into my head that the grep process of searching for a process is itself a process that gets searched by the grep process, I'm okay with the rest of the logic. Yep. Two wrongs don't make a right, but three lefts do...basic Unix rule of thumb. Thanks again. Brad

05-12-2003, 11:40 PM	#12
AHunter3 Hall of Famer Join Date: Jan 2002 Location: New York City Posts: 3,032	Thanks muchly! I'm really going to have to sit down one of these days and learn "grep"...

05-13-2003, 07:36 AM	#14
gatorparrots Major Leaguer Join Date: Dec 2002 Posts: 441	The -c flag on ps eliminates the need for the \| grep -v grep, which makes for a much more effecient string of commands.

05-16-2003, 01:04 AM	#15
XSage Prospect Join Date: May 2003 Location: Bedford, MA Posts: 8	Quite possibly the sloppiest solution imaginable is the killall command (/usr/bin/killall). Usage: Code: killall <applicationname> So if you wanted to kill the finder, you would do: Code: killall Finder That easy. Look at "man killall" for details. Last edited by XSage; 05-16-2003 at 01:16 AM.