Bugzilla – Bug 10162
server.log file growth
Last modified: 2009-01-05 09:42:52 UTC
server.log file has grown close to 1GB on my system and it dates back to the very first install (I believe). Perhaps the file should contain data to a configurable time period (i.e. 7 days), and create new files, perhaps at some interval marker, (i.e. every day) so that it will be easier/faster to access.
This is already implemented in SC 7.3: log files will be rotated when they reach 100MB size (Windows & OSX only).
Is there going to be a limit as to the total size of the log file(s)? If not would it be possible to add this as feature for future versions?
A maximum of two files will be kept.
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.
After upgrading to 7.3.1, and extensive SqueezeCenter "bug" reporting to server.log, the log grew to over 100MB, without being rotated. I am reopening this bug to let you know about this situation.
The logs are only rotated upon server startup. Kind of a "poor man's" log rotation that is, IMO, not suitable for a commercial software system. If, like many of us, the server is allowed to run for days, weeks, or months, the logs will grow indefinitely large. Why not stick a simple file size check into the logging operation so that this cannot happen?
Alex - the "poor man's rotation" only is triggered on SC restart. If your log grows at that speed, then we have a different issue to fix. At normal settings the growth shouldn't be more than a few KB, max. MB per day. But never GBs. Alan already fixed an issue which caused excessive logging. You might want to give the latest 7.3.2 another try. If this doesn't help, can you take a peek at the file (not easy to open, I know) and give a quick idea whether it's always the same message being logged? It might help us understand the root cause.
Unfortunately the errors I was receiving were related to 3rd party plugins and would not be fixed by you. That is why I raised this bug. But, the errors were of type "you are using function x, which is old, you should be using function y, it is newer. The problem has been traced into this large call stack of procedures" Perhaps this should only be logged if the user wants detailed logs for development purposes? Your call for such an enhancement, but the problem would still exist here. Given that a music server system would not need to be restarted at all, perhaps more frequent checking of the log size should occur?
Alex - don't you remember what the exact message was? Besides improving the log handling we should prevent any excessive logging if possible. Even if that plugin was calling a legacy sub, we might only want to log at a certain level, or every few seconds/minutes/calls/whatever. There's clearly room for improvement. Triode - do you know whether the the logger might rotate itself when files reach a certain size?
Created attachment 4543 [details] sample server.log
Unfortunately, I have deleted the large file with my 7.3.1 upgrade, and 3rd party plugin upgrades. Attaching a sample from my recent server.log for examples of the excessive details in the log.
Please make sure you update to the very latest 7.3.2 - one issue causing some this excessive logging should have been fixed by now.
Alan fixed a bug that was adding a lot of extra messages to the log. bug 10534 Hopefully that will improve things. Jim's comment that this method is not suitable for professionals is noted. Please let us know if it's still really a problem and we can reconsider.