Automatically restart crashed applications

I love Quicksilver. If I ever sit on a machine without it, I feel handicapped, like something extremely important is missing. My major gripe with Quicksilver (and, this might just be my setup, I’m not sure), is that it likes to crash a lot. At least 2-3 times a week. And when it crashes, it’s extremely annoying because when I need to start a program up I use, well, Quicksilver!

Updated 2008-01-11: Modified script for Leopard. New script at end of post.

I’ve found a couple of different methods for relaunching Quicksilver easily or automatically. One was to keep an alias to Quicksilver on the bottom-left part of your desktop with no icon, and named as ” ” (i.e. a space). So when Quicksilver is off and you want to start it, you cmd-tab to the Finder, hit space, and cmd-o. Quick, easy, does the job, but hardly clean (or nerdy!).

The other approach which I loved was playing around with launchd (found on MacWorld and macosxhints.com). With this service we can monitor a file for modifications, and when the file is modified we can perform an action. In this case, we would monitor the file /Users/username/Library/Logs/CrashReporter/Quicksilver.crash.log, and once its modified, launch Quicksilver. Clean, fully automated, but hardly simple. To make the task easier, Lingon can be used to deal with launchd. However, I was never able to make this to work, and I don’t have the patience to sit down and figure out what the problem is.

I did like the idea of monitoring Quicksilver.crash.log since that’s a direct indication that the application has crashed, but other than launchd I’m not familiar with any other automated service that can monitor for modifications in a file. I am however familiar with an automated service that monitors for modifications in a folder, courtesy of OS X, and that’s folder actions.

I can therefore build a folder action which will monitor /Users/username/Library/Logs/CrashReporter/ for changes, see what files were added, and if a ‘marked’ file was added then relaunch the relevant application and (this part is critical) delete the crash log so the script can work again. It took a couple of tries, but I think I found the most robust solution for this approach.

property restartLog : {"Quicksilver.crash.log"}
property restartID : {"daed"}
 
on adding folder items to this_folder after receiving these_items
    repeat with i from 1 to number of items in these_items
        set fileAlias to item i of these_items as alias
        set fileInfo to info for fileAlias
        set fileName to name of fileInfo as text
        if fileName is in restartLog then
            beep
            set itm to my list_position(fileName, restartLog)
            tell application "Finder"
                open application file id (item itm of restartID)
                delete item fileAlias
            end tell
        end if
    end repeat
end adding folder items to
 
on list_position(this_item, this_list)
    repeat with i from 1 to the count of this_list
        if item i of this_list is this_item then return i
    end repeat
    return 0
end list_position

Download this script

Note that to get this to work initially, you’ll have to open that folder and delete the existing Quicksilver.crash.log, otherwise this folder action will never kick in for Quicksilver!

The critical part are the two properties at the top. The first property contains the name of the file to watch for, and the second property contains (in the same order as in the first property) the application file id for the related application. The reason for using the application file id is that this will remain constant on every system even if the application is renamed by the user.

This script can be expanded to listen for any number of applications simply by adding the two parameters for each application to these properties. To get the application file id of the application you wish to monitor, simply run this code once in Script Editor while the target application is running:

tell application "Finder" to return creator type of process "Process Name"

and watch the output.

As a side note, with this method you can chose to do any number of things instead of just relaunching the crashed application since it’s straight forward applescript. In my version I chose to ‘beep’ as well, to let me know something went wrong (and the file trash sound is also a giveaway), but you really could do anything you want here.

Leopard Update:

There have been a few changes in the way Leopard handles the crash log files, which simplifies the use of this script. Instead of using a single crash log file for each application and appending to it, Leopard simply creates a new timestamped crash log in the form Name_YYYY-MM-DD-TIME_Hostname.crash. This is easier, because we no longer have to worry about deleting the crash log, we can simply check if the newly added log starts with *Name*. Therefore, a simpler version of the above applescript (that can only work with a single app, but switching to lists shouldn’t be too hard), follows:

property restartName : "Quicksilver"
property restartID : "daed"
 
on adding folder items to this_folder after receiving these_items
    repeat with i from 1 to number of items in these_items
        set fileAlias to item i of these_items as alias
        set fileInfo to info for fileAlias
        set fileName to name of fileInfo as text
        if fileName starts with restartName then
            beep
            tell application "Finder"
                open application file id restartID
            end tell
        end if
    end repeat
end adding folder items to

Download this script

If anyone can figure out how to use applescript instead of the shell commands and still have it work, please let me know.

Tags: Applescript, CC Licence, Folder Actions, OS X, Quicksilver
You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed. |

2 Responses to “Automatically restart crashed applications”

1. 1. Comment by Mark
   on 26 Oct 2007 @ 11:53 am

   Woot! This looks great. Others have other ways of doing it with automator actions etc… here but your idea is as you state, clean and nerdy. 🙂

2. 2. Comment by nofxx
   on 27 Feb 2008 @ 2:34 pm

   Never crashed here… use it everytime.
   Must be some unstable plugin we don`t share =D