Verifying program running in the background

Scripting Forums AppleScript | Mac OS X
, ,
#1

I use this script to verify if the AppX1 is running at the time this script is being executed.

if not appIsRunning("AppX1") then
	tell me
		activate
		set S to "Appy1" as string
		do shell script "open -a \"" & S & "\""
	end tell
end if

I would like to know what is the best way to have an application which is always running and which would verify if a certain application is running.

The idea is once the application Appx1 is no longer running Appy1 get started.

I would like to have the script running in the background with a loop to verify each 20 secondes.

My question what would be the best way to have something running in the background and not consume any memory?

Thanks!
Daniel

#2

Hello.

Try searching for faceless, idle, background, with app. :slight_smile:

#3 
on appIsRunning(a)
	return a is in paragraphs 2 thru -1 of (do shell script "ps -Ac -o command | grep -v ^ps$ ")
end appIsRunning
#4

or the vanilla AppleScript way (AppleScript 2 and higher)


on appIsRunning(a)
	tell application a to return it is running
end appIsRunning
#5

That was a nice one Stefan!

It isn’t intuitive, in that at least I believed it would fire up the app that isn’t running, but the app stays dead if it was dead. :slight_smile:

This works too, but is more cumbersome, I guess they use the same number of events, but your code is more robust, as sometimes, (but not often) the application name, and application process name are’t the same. Cf. OmniGraffle Professional.


on appIsRunning(anApp)
	local itsRunning
	set itsRunning to false
		-- Ask System Events if the apps name are among the names of the running applications
		tell application id "sevs" to if anApp is in name of every application process then set itsRunning to true
	return itsRunning
end appIsRunning

Edit: Your solution generates zero Apple Events Stefan, I find that funny, But then I guess every running process is part of the running environment of an AppleScript, so there are no queries to be made really. Hmmm. Time to read up a little in the ASLG.

#6

Another good place is ASRL

#7

Thanks!

All in all, it feels so good to be on a platform where you have a true abundance of tools (AppleScript being the most flexible one!) , and ways to accomplish things, it isn’t like this everywhere. :smiley:

#8

Correct but this way, or with system events, you can only check processes that are connected to windowserver’s console.

p.s. I’ve changed the code in my first code. Would mess up when somewhere bash is open.

#9

Thanks for all of those replies.

on appIsRunning(a)
   tell application a to return it is running
end appIsRunning

What I would have to do then is write an applescript program with the above code and have it running. For example, I would have this program to start automatically when the computer is turned on.

  • Would this be the approach ?
  • Would this be consuming a lot of CPU, memory… ?
  • Does it also, mean that there is no need for a ## of seconds delay loop ?

The intention is to have this script running on my MacMini Server.

What about this, is there an easy way to have the program sending a signal when it terminates running.
Something like "tell application ‘a’ to return “application C’ has stop running”

THANKS AGAIN!
Daniel

#10

Assuming you know the name of TheApp:

on idle
    if application "TheApp" is running then
       return 20 -- number of seconds of idleness
    end

    tell application "TheApp" to run
    return 20
end idle

Save as application, Stay Open, and put it in the login items of the user account, in the Accounts System Preference.
It will consume a very small amount of processing every 20 seconds.

#11

Take a look here, explains exactly how I use process control.

#12

i read that post, and I thought, how nice it is to have Mac OsX, that comes with launchd for taking care of launchAgents! :slight_smile:

I don’t think every 20 second will bog down anything, but it is very often really.

You make it quit by “tell application “TheApp” to quit” in a script!

#13

I hear some tone like it is more improved than other unix systems in there therefore I reply: Launchd doesn’t add any feature that wasn’t already there. All those job controllers overlapped each other and it was for Apple, not for the end user, easier to maintain it all in a single process. The XML file that needs to be send is much harder to maintain than inet files when you’re OS runs text based (no gui). So it’s not all better after all

#14

But it does require less thinking, and it is easier to get that right, than having to ponder over pid files like you did. My measure for whether something is good or not, is if it is easy to get right. And Launchctl owns every process.

I am not saying that you can’t conjure up something that is better, but launchctl makes it actually pretty easy to configure daemons right, even though it is based on xml-files, and is cumbersome to use.

But, for us that do AppleScript, this should be less of a problem, as we can control it all with applescript, stopping, starting, setting properties and so on.

And I was thinking of having a GUI, and not a FreeBSD or Linux box without gui, I have no problem editing xml with vi, should I need to. There is even a command plutil, that you can use to lint your plist files for erros.

It is also easy to administer, when you have just this interface to relate to (launchd and plist files).

Edit

You can compare items like this between the *nix’es but Mac Os X is beyond comparison really if you look at the full picture. :slight_smile: If you think that I’ll now start to talk about apple events, look and feel, and so on, you are right!

For persons that doesn’t dig into starting and stopping daemons on a daily basis I think launchd to provide a good interface for doing so. It also makes it easy to idenify which daemons and agents you really have. It is kind of initd for dummies, and I think that is a great thing when you are one of those persons that only touch this on a bi-monthly basis.

#15

The post I refer to is not using pid files and that’s the beauty of it. The power of parenting processes in unix is used here. Launchd is similar but what I don’t like is that launchd doesn’t look at the exit code. The disadvantage is that you need a separate process.

#16

You did indeed sort out a way to avoid using pid files.

That launchd doesn’t look at the exitcode, yes, that should be pretty disadvantageous when you need to know, but I guess there is written something about how to write such processes in the AppleDoc’s that says that you should write something to a logfile. Nevertheless, Getting an exit status to act on, is indeed useful, instead of just restarting it.

But I have used inetd in the past, and I must say that I prefer the way launchd does it, it feels at least as a much more uniform way of handling the stuff.

#17

I Agree, now there is one interface to do it all. It’s also a personal taste of course. The XML configuration is of cource better readable by software and therefore there are nice applications around there that can handle everything for you, like lingon.