Issue with stopping ColdFusion after starting from Builder

With the release of ColdFusion Builder there is an option available that provides the ability to start and stop one or more ColdFusion servers from ColdFusion Builder. In fact, you can configure CF Builder to automatically start a CF server when Builder opens, and stop the CF server when Builder closes. The autostart/autostop is convenient for a Development box where you want to minimize resource usage on the system. You can read more about this feature here.

Server Panel in ColdFusion Builder


Server Settings Panel in ColdFusion Builder showing Auto start/stop for CF Server

However, if you don't enable the automatic stop/start option, if you ever start ColdFusion server from Builder then close Builder without stopping ColdFusion there, then later you will not be able to stop the ColdFusion server using the standard ColdFusion stop script. I've encountered this on Mac OS X, but since its possible to configure CF Builder to start/stop remote CF servers, it's likely that the problem might occur when using ColdFusion server on Linux or Solaris as well, even though Builder doesn't run on those platforms.

Normally, to stop / start the ColdFusion server from the command line, you would the control script located (typically) at /opt/coldfusion9/bin/coldfusion, such as with ./coldfusion stop. That control script in turn invokes /opt/coldfusion9/runtime/bin/coldfusion9. When calling stop, the control script works by first grepping for any running ColdFusion processes with fgrep, like this: ps -axc | fgrep coldfusion9. If it finds a process listing that matches for the string "coldfusion9" then it stops that process.

Here's what you might see if you try to restart ColdFusion from the command line after it was started but not stopped from Builder:

The problem of not being able to use that control script to stop ColdFusion server after having started it from Builder arises because of how Builder starts the CF server. Rather than invoking /opt/coldfusion9/runtime/bin/coldfusion9, Builder instead invokes /opt/coldfusion9/runtime/bin/jrun. When the control script tries to grep for the process with a "coldfusion9" string, the control script doesn't find it because Builder invoked runtime/jrun instead of runtime/coldfusion9.

Why the need for runtime/jrun AND runtime/coldfusion9? I have no idea, especially since the files are identical and not symlinked.

I logged ColdFusion server bug 82573 for this where I proposed a change to the bin/coldfusion control script. My suggested change was only shown for Mac OS X, but you can easily change it yourself for the Linux or Solaris blocks in a similar way.

If you want to use my suggested fix on your local Mac OS X dev box, then you can refer to the full example control script containing the fix here: http://pastebin.com/Y7r6sDGu.

For brevity, I won't show the whole script in this blog entry. Instead, here's the diff between the backed up original coldfusion control script which I renamed to 'orig.coldfusion' compared to the fixed version 'coldfusion'.

Comments