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 start CF from the command line, then the same info is written to the command line instead and not to the log file.)
(If you're on *nix, pretty much the same info appears instead in the [cf]/logs/cfserver.log. I know some people have wondered about controlling the size of that file. What I discuss here applies only to Windows.)
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:
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:
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:
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):
(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):
If somehow it's not there, it would report:
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:
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:
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.
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:
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.