"nolioserver20-stderr" Log File Blowing Up

[Christopher Farrar]

Good Morning,

 

I've had a long standing issue in which a particular file "nolioserver20-stderr.<date>.log" grows to fill any remaining space on my RAC server data drive.  This only seems to happen once every 3 - 4 weeks and is easily resolved by stopping Nolio services, deleting the log file and then restarting but I am curious, has anyone else seen this issue?  Has anyone had any success in permanently resolving the issue?  It is not a gradual increase either... the file will remain around 200 - 400 KB and then all of a sudden just grow to eat up any remaining space on the drive (usually 40 - 45 GB).  Given the size of the file, it is difficult to capture any output but next time that it happens I will try and use a specialized text editor to capture some of the content and update the post.  I'm thinking that there must be a way to modify either the configuration to resolve whatever issue is causing this file to grow or modify a logging option to turn off whatever logging is responsible for causing the file to grow so exponentially.  I'm also curious as to which log4j.properties options control this logging file.  I believe that I have my log size and rollover options configured correctly but I would like to verify if I can determine which section is responsible for generating this log. Any information is good information at this point so thank you in advance, I look forward to hearing everyone's input on this.

[Gregg Stewart]

Hi CJFarrar,

 

Sorry for the delayed response. This sounds like something a support issue should be opened for so that we can:

a. get to the bottom of why those files are being created; and

b. look into whether or not the stderr files can be configured to not exhaust available disk space.

 

 

Regards,

Gregg

[Christopher Farrar]

Thanks for the response Gregg.  I have a support case open, things go a little stalled on it for a while so I wanted to get some feeback from the community to see if we were overlooking something.  At the moment, I am working with support to temporarily disable the stderr logging until we can determine what is causing the error and how to resolve it.  I will update as more information becomes available.

[Anon Anon]

Hi CJFarrar,

 

This could be caused by an infinite loop.

When the standard behavior that fails the deployment process when errors happen had been modified (for some reasons, e.g. error handling for known errors). The reason for modifying the default behavior might be valid. However some unforeseen circumstances happened that was not handled properly. The faulty handler produced an infinite loop.

 

We experience the similar thing which caused by such infinite loop, however the one that noticeably blew up at that time was the Oracle database tablespace.

[Christopher Farrar]

Thank you for the response.  We don't currently use any Oracle databses with our current implementation but we do use the fail deployment step action in a couple of our deployments so that is a possibility.  I will run this past support and investigate a little further on my side.  I'll be sure to update if it leads me to a resolution.  Thanks again!

[leiwe03]

Hi CJFarrar,

Have managed to get this resolved with the help of Support yet? I am having the same problem and it would be great if you already found a solution.

Thanks

Werner

[Christopher Farrar]

We are currently on 6.3 and we haven't seen the issue since we upgraded to 6.2 (a few months ago).  If I see it pop up again then I will be sure to post something to the community about it and tag your ID but as far as I can tell, it was fixed for us with the 6.2 update.