[Looking for Charlie's main web site?]

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

Note: This blog post is from 2010. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
As a CF user or administrator running CF 6-9 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.

Update for CF10, forward: CF10 and above change to using a new set of xml entries in the neo-logging.xml file, called maxOutLogSize and maxOutFileBackup that should control this (and which should not to be confused with the long-existing maxFileSize and maxFileBackup, both of which correspond to the settings on the CF Admin logging Settings page.) That said, some users had found in the early updates of CF2016 that somehow the xml entries were NOT being honored. It's not clear from them if later updates did fix that problem. I've not heard it as a widely-reported one.

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:

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 use it to set it to a number larger number than 1000, and then "tweak" that value via the registry if you want. The value's name should be LogFileRotationLimit (a new>string if you will create it yourself).

FWIW, 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.

For more content like this from Charlie Arehart: Need more help with problems?
  • If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
  • See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
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?
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.
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.
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.
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
Thanks for the update, Ciaran, and for the pointer from the SO site. Hope the entry helped and may help others in the future.
Thanks for this Charlie. I have CF 9 Standard installed on redhat. The problem I have is I can't seem to find jrunsvc.exe. I searched the whole server and found nothing. My windows box has it though. Would it work to copy it from my windows box? If not, any idea how I can get my hands on it so I can limit my log size?
# Posted By Matt | 8/15/12 8:04 PM
Matt, as I discuss in the entry, this is about the log created for running CF as a Windows service. It does not apply to Linux. (I stated that above, though I have just tweaked the wording a bit to make that statement more clear.)

As I had noted in that statement, you'd find the equivalent info in the [cf]\logs\cfserver.log file. (And as for controlling its size, the approaches here do not apply. But since you don't mention yet using that file, maybe that's not your issue anyway.)

Let me know what you think.
Thanks Charlie. I missed the part about being a windows service only... I was skimming :). Yes, the cfserver.log file is my issue... I'm trying to control it's size. Any idea how to do that on linux? I can't seem to find anything online.

Thanks for any help you can give!
# Posted By Matt | 8/16/12 11:11 AM
So I just had an experience on Coldfusion 11 Enterprise on Windows 2012 server where our \cfusion\logs\coldfusion-error.log started growing uncontrollably.

It filled the 50G volume it was on, and when our sys admin expanded the volume another 50G it had grown to 87G before I killed CF and deleted the file.

Not sure how that could happen as my "Maximum file size (in kilobytes)" in the CF Admin is set to 5000. All the other logs are 5M max.

Just wanted others who visited this page to know in case they experience it as well. Not sure where to post these things anymore to get any help since many CF sites are either unused or have shut down. Really miss CF-Talk.
# Posted By dlegate | 11/20/16 3:26 PM
dlegate, sorry for the delay in getting back to you on this.

So that's VERY interesting to hear (that you're CF11 coldfusion-error..log grew uncontrollably). It shouldn't have, though not because of the setting you referred to.

Let's clarify a few things:

- obviously this post of mine here is from 2010 and so was written about CF9, and as you may know CF10 and above are built on Tomcat whereas CF9 and before had been built on JRun
- because of that, most of the specifics of this post are quite different though the concepts are similar
- (one nice advantage of CF10+ is that the coldfusion-out.log and coldfusion-error.log files are now stored in the regular CF logs folder like other CF logs, as in a folder such as \coldfusion10\cfusion\logs)
- I can confirm that BOTH the coldfusion-out.log and coldfusion-error.log files in CF10+ DO indeed have a default size limit of 20m, so you really should not have seen it runaway like that
- but just like in CF9 and earlier, that limit for THOSE files is DIFFERENT than the limit set in the CF Admin, as you referred to. That admin settings controls all the OTHER logs (like application.log, exception.log, cfhttp.log, and so on) but specifically NOT the -out and -error logs
- as for HOW to control the size of the -out and -error logs in CF10 and above, the solution is quite different from that which I discussed above in this blog post. That involved a service definition configuration, aka a registry tweak.
- Instead, with CF10+ , you would edit a new xml element you will find is now provided in the neo-logging.xml file (in your CF instance's /lib folder). This was discussed an Adobe article from that CF10 era: http://www.adobe.com...
- but back to your specific challenge, I can confirm that my coldfusion-error logs are following that setting and DO rotate when they reach that setting (the default of 20m). Also, though the xml setting is called maxOutLogSize, it applies to both type of log files (coldfusion-out and coldfusion-error). Again, I confirmed this with testing.

So again it is indeed curious that you experienced that. I can't imagine what may have been the issue.

But here's a thought: what CF11 update are you on? I am on CF11 update 11 as I am testing this. If you're on some earlier release (or were back in Nov when you wrote), perhaps something was changed in one of the updates, though I don't recall noticing it.

Let us know how things turn out. In the meantime, I hope this info may help others wondering about CF10 and above.
I never heard back from dlegate here, but in case anyone else runs into this, you may want to consider still more (and more substantial) help/suggestions I gave to someone ELSE reporting the same problem (of the coldfusion-out.log increasing beyond the maxOutLogSize set in the neo-logging.xml file).

There are really several possible configuration issues that could lead to the problem, but perhaps it really is none of those and some bigger problem. We'll see.

See my (long) comment here:
https://forums.adobe...

And in time hopefully he and/or others may share more. If we learn anything significant that could affect others globally, I would hope to report back here with more.
Charlie,

what is the linux counterpart for:
jrunsvc.exe

thank you,

Angel Madera
Angel, are you really asking that specifically? Or might your question really be more in the context of the point of this post: about controlling the size of the "out" logs that CF creates?

This 2010 post shared how to solve that (in the CF9 era) for Windows, using the jrunsvc.exe, which is where Adobe embued the ability to control the size of the out logs.

As for an equivalent in Linux, well as you know, CF runs as a process named Java, and that gets started either by the equivalent of a Linux service or CF's bin/coldfusion.sh start command. But sadly Adobe never provided for a way to control the out log file size in Linux (until CF10). You can see this discussed in a technote from Adobe, which while it's no longer on the Adobe site, you can read it via a 2009 version at archive.org here

https://tinyurl.com/...

Let me know if that answer suits what you sought.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting