Do you use a background-only application (no dock icon) that’s critical to your workflow? Something like Quicksilver, Butler, LaunchBar, or SnapzProX ? Like nearly all OS X applications, these programs don’t crash very often. However, when they do, it can be troublesome, because they usually just sit there quietly in the background, waiting for you to do something. You only notice they’ve crashed when you try to use them to perform a task. You then relaunch the program, and it goes back to work in the background. Wouldn’t it be nice if there were a way to automatically restart a crashed application?
If you’re running
OS X 10.4, you can do this by taking advantage of the system’s
handles all of the systems daemons, for things like networking, web serving, and printing, but it can also launch user daemons, which is what we’ll use it for in this hint. By taking advantage of a
feature, we’ll be able to create a daemon that watches for the evidence of a program crash, then restarts the program. While you can create this daemon yourself, we’re going to use a free open-source application to help speed the process—if you want to do it on your own,
explains the steps you need to take.
For my example, I’m going to use SnapzPro—because it’s an application I use constantly, and I need it to be always running. This is not to imply that it crashes any more or less often than any other program, but I had to use something as an example!
Start by downloading
Lingon, a graphical interface for creating
daemons. After installing Lingon somewhere on your hard drive, launch it and click the Assistant button in the toolbar. Since we’re creating a task to relaunch a crashed application, select “Run an application/script when a file is modified.” You might think that “Keep an application/script always running” would be the proper selection, but if you use that option, then you won’t be able to quit the program even when you want to! Using this approach, we’ll just make sure the program restarts after a crash, allowing you to quit it yourself if you want to. Click Next to proceed to the Label dialog, which is where you’ll name your new daemon. The name you choose must be unique on your machine, and it should use “reverse domain naming,” to match the convention used on OS X. I named my action com.robg.SnapzWatch, as seen here:
You can leave the other options as they are, then click Next. The final Lingon screen is where you specify what file will be launched, and what file to watch for changes that will cause the specified program to launch. For the program, click on the Path button, and then navigate to the program you’d like to relaunch when it crashes. The only trick here is that you want to point to the actual executable file within the application bundle, not the application bundle itself (the file browser in Lingon will drill down into packages automatically to make this easy to do). For most OS X programs, you’ll find the executable within the bundle in the Contents -> MacOS folder. For example, when I navigated to the Snapz executable, Lingon filled in the path: /Applications -> Snapz Pro X (the folder) -> Snapz Pro X.app (the application bundle) -> Contents -> MacOS -> Snapz Pro X (the actual executable). Once you have the program info filled in, drop down to the File box. This is where you’ll tell
which file to watch for changes that indicate a crash has occurred.
You might wonder what file you can watch in order to tell when a file has crashed. The answer is that when a program crashes, it’s supposed to write a crash log into your user’s Library -> Logs -> CrashReporter folder. If the CrashReporter file for a given application has been changed, then that means that program has crashed, and it needs to be restarted. So in the File box, just navigate to your user’s CrashReporter folder and select the file from the crashing program. For Snapz Pro, that’s Snapz Pro X.crash.log. Once that’s done, click Create and you’re finished. From now on, if Snapz ever crashes, it will automatically restart again.
Note that the crash log file
must always exist
in order for this to work. So if your app hasn’t crashed yet, you really can’t use this tip (as you don’t know exactly what the log file might be named). If the log file ever vanishes, then
will stop watching for changes (since it can’t find the file). If that happens, you’ll need to make sure the file exists (easy in Terminal,
to the proper directory first, then
touch “Snapz Pro X.crash.log”
), then run Lingon again and click the Reload button for your agent.
Ideally, we’d take the time to send the log file to the developer, figure out why the crash happens, and prevent it from happening again…but sometimes, when deadlines call, we just want to get back to work. Lingon and
make that about as easy as possible.