[Looking for Charlie's main web site?]

CF911: How to control the size of CF's -out.logs

As a CF user or Administrator running on Windows, have you ever wondered how to increase the size of the console logs (-out log files in the [cf]\runtime\logs directory, or [jrun]\logs in Multiserver)? This entry will tell you how. It's quite easy to do, but it's not done using usual log file size control settings in CF's Admin or XML files.

The quick answer is to use either of two approaches: either the jrunsvc.exe in CF's runtime\bin (or [jrun]\bin), or do a manual registry tweak, both of which I show below.

BTW, if you don't know what CF's -out*.log files are about (they're important!), they're technically holding the console output for CF, when it's started as a Windows service. This can be vital information that is NOT logged in the normal [cf]\logs directory or Admin Log Files display.

(If you're on *nix, the same info appears instead in the [cf]/logs/cfserver.log. I know some people have wondered about controlling the size of that file. I don't think what I discuss here does apply.)

Finally, if you start CF from the command line, then the same info is written to the command line instead and not to the log file.

Background on the sizing of the -out*.log files

You may have noticed that the default (since about CF 7) has been for these to grow no larger than 200k (not 200mb, but 200kb!), and up to 200 occurrences of them per instance.

Certain kinds of problems can lead to a lot of information being written to those files, such that in some instances, a given -out log file will contain only a few minutes of data (if that). And if too many of those happen, old log files will rotate off and you may soon not be able to see much than hours or days ago. It would be helpful, then, to let these files grow larger, both to make it easier to look at anyone and see a longer period of time in it, or to allow the sum of rotations to cover a longer period of time.

At the default of 200kb * 200 rotations, that's 40mb at the most that the files can use. I think most servers these days have a good bit more disk space they can afford to use! :-)

Even at 2000kb (2mb, a 10-fold increase), that would still be only a max of 400mb, or less than half a gig. Most drives these days can afford that. :-) How large you want to make them is your call.

Just beware of the temptation to perhaps lower the rotations and increase the size (like 100mb * 4 rotations). The larger the files get, the less likely you'll be able to easily open them with simple editors like NotePad (which starts to get slower to open, the larger the file is). That said, I can point out a great alternative tool for looking at larger files, though. I just blogged about it, Universal Viewer.

(Actually, prior to CF7, there was a bug where the -out.log file would grow unchecked and could itself grow to a GB, which is one the first reasons I learned about Universal Viewer. More on that issue and the fix for it in a moment.)

As for the filenames and rotations, if you've not noticed it, they use the instance name and a sequence number, such as coldfusion-out.log for the latest out.log (for a standalone CF instance), or myinstance-out199.log for the 199th rotation of a given instance's out log. The rotations starts with 1 until (the default of) 200 is reached, when it starts reusing the numbers starting at 1 for the newest logs. As such, at least until that rotation max is reached, the lower the number, the older the log.

BTW, If you wonder, the sequence number is kept in the registry, as another string value defined for the service (see the discussion below), as CurrentOverwriteLog. If you find that the logs are not rotating, that's a problem of permissions in the registry. If you've changed the user under which the CF service runs, you need to give that user permission to update this key. That's fodder for another blog entry some day.

You can't change these log's size and rotation values in the CF Admin, nor in jrun.xml!

Unfortunately, setting the size and rotation for these files isn't as simple as making a change in the CF Admin. You may notice that there is a setting on the Debugging&Logging>Logging Settings page for "Maximum file size" and "Maximum Number of Archives", but that setting controls the traditional CF logs (those shown in the Admin's Log Files page, or found in [cf]\logs, or deep within the directories for an instance in Multiserver mode.)

Also, some may know that there is an available jrun.xml file that has a jrunx.logger.FileLogEventHandler entry with available rotationSize and rotationFiles attributes, but those only control the -event*.log files (even if you tweak them as suggested by an old Macromedia technote). BTW, if you're interested, that file was in the [cf]\runtime\bin directory in CF 6.1, but since 7 it's been in [cf]\runtime\servers\coldfusion\SERVER-INF (or [jrun]\servers\[instancename]\SERVER-INF on Multiserver).

So how, then do you increase the size of the -out*.log files? Yes, we're finally ready for the "big reveal".

Supported approach: Using the jrunsvc to change the logfilesize and rotation

The good news is that it's fairly easy to update. You just need know your service name and the size you want to set, and then run the jrunsvc.exe command to make the change. It's found in the [CF]/runtime/bin or [jrun]/bin directory.

For instance, for a CF9 Standard or Enterprise Server mode service, whose name (as shown in the Services Control panel) is "ColdFusion 9 Application Server", you might use:

C:\ColdFusion9\runtime\bin\jrunsvc.exe -logfilesize 1000 "ColdFusion 9 Application Server"

You may need to tweak the start of the command, if your CF installation is in somewhere other than c:\ColdFusion9.

The great news is that CF will start leveraging the change immediately, even without a restart.

If you're in an Enterprise multiserver (multiple instance) deployment, the command is instead in C:\JRun4\bin, and of course your service name varies depending on whether it's the cfusion instance, in which case its name is "Macromedia JRun CFusion Server" (yes, it's "Macromedia", even in CF9), or an instance you've added, which may be "Adobe ColdFusion 9 as Instancename". Here's how to do it for the cfusion instance:

C:\JRun4\bin\jrunsvc.exe -logfilesize 1000 "Macromedia JRun CFusion Server"

Pretty simple and sweet. The logs have lots of great info, so increasing them can be really valuable and is something I help people do all the time as I help them solve problems in my CF server troubleshooting consulting services. Hope it helps you.

How'd I find this out?

So how did I find the jrunsvc was the solution? And what are the details? Well, it's is actually buried at the bottom of an old Adobe Hotfix note for CF7, which you would reasonably never think to look at if you were on CF 8 or 9.

But the information it offers does apply (after you apply the hotfix at the top, if indeed you are on CF 7.01 or 7.02. This is the solution to the problem where the -out*.log files would instead grow unchecked in size), even on CF 8 or 9.

How will you know that the change takes effect?

Well, of course you can watch the files to see if they grow larger than the default size. But you may prefer to check without waiting so long. :-) That leads to the next point.

Shortcut: Use the registry to confirm or indeed make the change

It turns out that this jrunsvc command simply updates the Windows Registry, with respect to information about the Windows service, so you can also confirm the change by looking in the registry. Better still, you could just skip doing it from the command line and just do the tweak yourself.

You can do it either with a gui like the windows RegEdit tool, or using the command-line Reg command.

And of course, the standard disclaimer about working with the registry applies: here be dragons. :-) If you make a mistake in editing the registry, or mistakenly delete something, it can have negative effects on many things. (But then some mistakes, like giving the wrong name to a new key, might cause no problem at all.)

This particular tweak is really quite simple (adding a single, simple key) and it's safe, if you're comfortable with registry tweaking. I've done it now on several dozen machines and never had a problem.

There's simply a key where all Windows Service settings are stored, and it would have one for each instance of a CF service you may have. For the CF9 Standard or Enterprise Server instance, it would be a key at:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ColdFusion 9 Application Server

And it would have several values related to the CF service, and the value we're looking for is LogFileSize. Before executing the jrunsvc command above, there is no value for the key (by default), and so again CF defaults to a size of 200.

(BTW, don't be too confused by registry terminology. We might think that we're talking about a "key" named "LogFileSize" with a "value" of "200", but the registry instead uses "key" for the location (that longer string I referenced in the colored code block above the previous paragraph), and it calls this thing we're looking for a "value" and the number it would be set to is technically called "data". You can see this also if you use the "find" feature within RegEdit.)

Checking or Adding with the REG command

Anyway, if you want to confirm that the change you may have made with the jrunsvc (as above) took effect, you should be able to see it with this command-line command (for the service name we've been referring to):

reg query "HKLM\SYSTEM\CurrentControlSet\Services\ColdFusion 9 Application Server" /v LogFileSize

(Yes, I'm using a supported shortcut, with that initial "HKLM", as being short for "HKEY_LOCAL_MACHINE".)

It will report (if you set it to 1000):

LogFileSize REG_SZ 1000

If somehow it's not there, it would report:

ERROR: The system was unable to find the specified registry key or value.

I should note that you would also get that same error if you either pointed at the wrong service, or indeed gave the name of a service that did not exist at all, so be careful.

As for how to add the new value via the REG command, you would use something like this:

REG ADD "HKLM\System\CurrentControlSet\Services\ColdFusion 9 Application Server" /v LogFileSize /t REG_DWORD /d 1024 /f

It's about the same effort as using the jrunsvc command above. One advantage of this approach would be that if had to do this for dozens or hundreds of servers, you could use something like PowerShell to script it, and it has built-in support to work with the registry that might perhaps work more easily than scripting the jrunsvc command above.

Checking or Adding with the RegEdit GUI

Finally, for those who prefer the gui, just launch regedit (google to find out how to do that, though perhaps if you don't know what you're doing, you may want to pass on this, or get some help.)

Once regedit is open, drill down to that key location named above. Once it's selected, see if you see a value for LogFileSize there.

And if you want to add it, while there (with the cursor on the name of the key (such as HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\ColdFusion 9 Application Server), you can right-click on the values on the right and choose "New" (or in the Gui's top menu use Edit>New>) then choose String Value. Provide a name of LogFileSize and hit enter.

Then double-click on that new key, and enter 1000 for a value (if you want to change the size from the default of 200k to 1000k, or 1mb.)

The great news is that, as with the jrunsvc command, CF will start leveraging the change immediately, even without a restart.

What about changing the rotation count?

I'll note as well that, though not mentioned in the technote, if you run the jrunsvc command with a /? argument (or any invalid argument), it shows that there is also an option said to control the log file rotation: -logfileRotationLimit. But when I try to use that, even just to set it to the default of 200, it curiously replies with the error:

Error: log file rotaion limit must be at least 1000

What? (BTW, that misspelling of "rotation" is indeed in the error message.)

It makes no sense that that should be required to be "at least 1000". Perhaps someone from Adobe may want to look into this.

Oh well, you can at least change it via the registry tweak if you want. The new>string value's name should be LogFileRotationLimit.

FWIW, if somehow that error above is resolved, I'll note that you do need to provide the two arguments each in its own separate jrunsvc command, it seems.

Summary

I've confirmed from my own servers and others that making this change (either way) does indeed let the -out*.log files grow larger, which is a great help when solving certain kinds of troubleshooting problems.

In conclusion, I'm surprised to find that if you search google for the phrase:

"jrunsvc" "LogFileSize"

the only hit found (prior to me writing this) was that one Adobe technote (and one with the technote in Japanese). I'm stunned that no one else may have ever mentioned this. I know I've seen other blog entries where people have mentioned that they, too, had noticed that the traditional solutions (and even some other hotfixes) did not solve the problem of how to change the size and rotation of the -out*.log files.

While I do hope that many people will benefit from this entry, I will admit that there's a real sense of discovery and some awe when one gets to "walk" where seemingly few have gone before. :-)

Let me know what you think, whether you read this within days or years of this being published. Cheers.

Comments
Thanks for the write up. I came across this problem a while ago and posted about it on SO (http://stackoverflow...). My specific problem was System.out. I ended up editing jrun.xml, but the frustrating thing was any upgrade of CF wiped my good work. Is there any way around this?

In the end we dealt with it via CF - when our application starts for the first time we archive off the file via CF. Can you see any problems with this approach?
# Posted By Ciaran Archer | 3/11/11 6:15 AM
Ciaran, I'm curious about your reference here (and on your SO posting)to system.out, as being (you say there) "where console output ends up when running CF as a service". I have simply never seen that to be the case. Instead, it has always been this coldfusion-out.log in the runtime\logs (or other names/places in different deployments, as I refer to above).

So before going any further,I would think you must have made some other edit (perhaps in jrun.xml, or in the startup batch files, the service definition, or perhaps the registry, per my discussions above) to cause it be writing the console log a system.out log, especially in the runtime\bin dir.

Now, all that said, the mechanism in place seems solely what I offer: a limit to the size and rotation number. I'm not aware of there being any way to get the per-startup file creation you seek.

I see some offered ideas to that regard in the SO answers. I would have thought (from my experience) that the jrun.xml edits DO NOT APPLY to this console log file, again as I discuss in the entry above.

If you find anything to the contrary, please do let me/readers here know. Also, some may want to hear about the code you say you use to implement a forced clear of the files at each startup.
# Posted By Charlie Arehart | 3/12/11 4:04 PM
Hi Charlie

Could this be related to the fact that we use:

sys = createObject("java", "java.lang.System");
sys.out.println(...);

Could it be that this is creating the output in runtime/bin/System.out?

We used to use it a lot when coding to see output when running coldfusion in the console (rather than as a service) but I think improvements to cflog mean than any logging done is output to the console anyway. So we're going to advise developers to use cflog (even if it's just to the application log) for now.

This could be a quirk just with our organisation but since others suggested some answers on Stackoverflow I guess others might be having this issue too. Perhaps they are using system.out.println() too?

Anyway - just thought I'd mention it.
# Posted By Ciaran Archer | 3/14/11 5:32 AM
Ah, ok, sure, I could see that causing it (the writing to the system.out log), and I could see someone doing it for the reason you note, though as you observed, CF has for some time also written any CFLOG output to the console (or the console log discussed in this entry) instead, for better or worse.

So then the question becomes: if you are indeed causing this writing to the system.out file, and you for some reason wanted to keep doing it, how could you control its size. It would be interesting if neither the jrun.xml entries in the so answers nor the approach I describe above would control it.

In that case, it may just be better to stop doing it. If you think it may help readers of that SO entry to see some of the info here, whether in the body or in these comments, feel free to point to it there.

BTW, if you do change to using CFLOG, note that while the default is for it to write to the application.log (as well as the console log), you can change it using the FILE attribute to point it to any other filename, if you wanted these custom log entries to be segregated from other normal application.log entries.
# Posted By charlie arehart | 3/14/11 9:30 AM
Hi Charlie

We're decided to stop doing this - so we'll use the <cflog> tag or writeLog() function instead. We do use <cflog>to log to proper application-related logs too, and I have to admit the <cflog> tag is a pleasure to use these days.

Thanks for all your feedback - I updated the SO question and commented on the answer too.

Cheers, Ciaran
# Posted By Ciaran Archer | 3/14/11 11:11 AM
Thanks for the update, Ciaran, and for the pointer from the SO site. Hope the entry helped and may help others in the future.
# Posted By Charlie Arehart | 3/14/11 2:01 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.005.

Managed Hosting Services provided by
Managed Dedicated Hosting