Help with CF Server Instances Failing to Run

[John_Allred]

Hello,

I'm running CF 2018 in Developer mode on my local PC running Win-10 64-bit. Over the past year, I've created several server instances on the Coldfusion Server, and I've had no problem, other than that a couple of them have required periodic restarts. Recently, one of them failed to start at all. As I dug into it, deleted the server instance and attempted to create it anew or create other server instances, I discovered that I can no longer create a server instance that will start and run. FWIW, this is true whether I select the option to create a Windows Service or not.

I've opened the Windows Event Viewer, and I don't see anything that would point me toward a solution. But I have little experience at interpreting server logs.

I'm wondering if it might work to delete CF 2018 from my C: drive and install it on a different drive.
Or, as I hope, is there a simple fix for this?

Thanks!

John

[Dave Watts]

I'd try running it from the command line, as an application, and see what if any errors you get. You'd use C:\ColdFusion2018\[service name]\bin\cfstart.bat to do that.

Dave Watts, Eidolon LLC

[John_Allred]

Thanks for the suggestion, Dave. Running that file put the cmd screen up for 10-15 seconds, and then it disappeared. Never saw any text. Certainly no error messages.

~john

[Charlie Arehart]

John, it sounds like you missed a key point Dave shared, "try running it from the command line". The pop up you refer to is when you just run the bat file from the file explorer.

With this approach you'll see what is being written to the command line, which should give a far more clear clue as to why the instance is not starting or staying up. If you don't readily connect the dots, share here what you see.

There should bni need to reinstall CF, no. 

[John_Allred]

Charlie, you and Dave are always so patient and helpful. Thanks!

Running the batch file Dave suggested, I get the following which, of course, makes no sense to me.

"ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [:732]"

I ran it in under two different servers that won't run, and the message is the same.

If I run it under a server that runs, I get a more benign message.

"Either the server is already running or some other application is using the HTTP port 8502."

Thanks,

~john

[Dave Watts]

So, sorry for responding so slowly here, and skipping over some things. First, make sure you run the command line as administrator. Anything that needs to assign ports etc usually needs to be run as administrator. Second, make sure you're not running the corresponding service at the same time.

Dave Watts, Eidolon LLC

[Charlie Arehart · Accepted solution]

And now I have to apologize, too, as I didn't get to respond to your reply over the weekend (and here you had offered such kind regards to Dave and me!)

So I think now I know what's happening. Notice the error refers to jdwp. That's the debugger. It seems you enabled (or didn't notice that the cfusion instance was configured to enable) the "cf debugger". It's in the Admin on the "Debugger Settings" page (not the "Debug output settings" page).

Anyway, the problem is that the newly created instances inherited that setting, and now they TOO want to "start the debugger", which is a port set in that admin. I realize you can't get to the admin in the instances that won't start, and while you COULD go into the CF admin of the cfusion instance to turn it off, and then create the instances again, you do NOT need to do that.

Instead, open the jvm.config file in the bin folder under each instance (so for an instance called instance1, it would be in coldfusion2018/instance1/bin/jvm.config). In that file, find the java.args line. On that line, you should find something like this, likely at the front of the line:

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005

And if the cfusion/jvm.config and the other instances all use that port 5005, that's the problem. If this is indeed the problem, there are various ways to solve things.

First, you could change the port in that file (for the instances, to like 5006, and the next to 5007, and so on). If you do that with one, and save the file, does CF now start (as a service)? If it does not, repeat Dave's suggestion to start it from the command line. If that solves it, great. You could then go into the Admin, to the debugging page, and "stop" the debugger.

Or you could REMOVE those args, but I would recommend you save a copy of the file first. It's easy to make mistakes when removing things. Or better, you could comment them out by putting them on a new line (just those args) and put a pound sign in front of them, after removing them from that java.args line. Then try starting CF, and follow what I shared in the last paragraph.

Let us know how it goes.

[John_Allred]

Charlie, once again, I can't thank you enough. I checked the port numbers in all seven of my server instances. The two that wouldn't start, indeed, shared a port numbe with a third that WAS running. I changed those port numbers and, voila!

The debugging is a feature, not a problem, and I didn't change that setting, although I did switch it off on the top level, 8500 port.

[Charlie Arehart]

Great to hear that it's resolved, of course. But some will wonder: what in fact WAS the port that you had to change? If you just share the number, I could likely tell what aspect of CF was using that (as could others).

But it seems you're saying it was NOT the debugger ports? In that case, it would seem confusing to readers for you to have marked my last answer as the "correct" one. Hoping your response will clarify my confusion. 🙂

[John_Allred]

So sorry to have produced any confusion.

In answer to your question, one server's jvm.config file had the following:

# Arguments to VM java.args=-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5012. That one was working.

I had two others that, even if I deleted them and recreated them, or if I created a new server from scratch (I now know) they would use this same address of 5012. In the two servers I needed to get running, I changed 5012 to different port numbers. That fixed them.

As for your point about the debugger, correct me if I'm wrong, but there are two contexts for debugging. Perhaps I confused them, inadvertently. I meant to say that I have the page-level debugging output for each of my servers enabled, but I turned it off at the top level (8500).

About the debugger in any other context, I know not. Does that clarify your question?

[Charlie Arehart]

OK, so it was indeed the debugger. And yep, changing that port was one solution (as I indicated in my reply that you marked as "correct"). Thank for clarifying.

As for different concepts of debugging, your confusion is understandable. The "debug output" you refer to is set on the CF Admin "debug output settings" page, and that controls CF showing info at the bottom of pages, depending on the settings on that page.

The "debugger" is totally different, and controlled first by the settings on the "debugger settings" page I'd mentioned, as well as the JVM args I'd mentioned (and you refer to), the Xdebug and Xrunjdwp and its port.

This "debugger" is instead the interactive step debugger, supported by CFBuilder, and available in CF since CF8 when it was first introduced. This (if configured properly) would allow one to step through code, line by line, within the CFBuilder IDE.

And yes, since doing that debugging requires such a port (in CF) for CFBuilder to connect to, that's why it's indicated in that arg, and as I said, when you create a new instance, the CF Instance Manager brings forward the same JVM args--for better or worse, the latter in this case.

Hope that helps. If still confusing, again that chapter I linked to explains it in more detail. Otherwise, don't worry about it. Your problem is solved, and that's what matters. 🙂 Glad to have helped.