Bugzilla – Bug 1943
Rotating SlimServer logs
Last modified: 2009-09-08 09:13:37 UTC
I run SlimServer with logging enabled to help with whatever beta debugging I can. It's been very stable lately, but will crash on the rare occasion. The log file commonly grows to 1/2 GByte or more without my noticing. Then when there's a crash, I have to deal with opening an enormous file. And if I do notice that the log has grown to enormous proportions, I can't delete it without first shutting down SlimServer. Create a logging preference to designate the directory where SlimServer logs are written, then optionally rotate the logs daily using something like a yy-mm- dd.log naming convention.
Jim: What OS are you running on?
Currently it's XP Pro. I realize I could script something, but if I'm not mistaken it would require stopping and restarting the SlimServer service.
My SC7 Windows scanner log has just grown to 1gb... my server log to 0.25gb, causing Windows to report disk full alerts. Wouldn't it be best if the scanner log file was deleted and recreated afresh when a full wipe and rescan was performed? Logging is enabled by default isn't it, so this growth will become a problem over time for many users with large libraries? I certainly don't remember adjusting any logging preferences since my last complete reinstall three weeks ago.
(In reply to comment #3) > My SC7 Windows scanner log has just grown to 1gb... my server log to 0.25gb, > causing Windows to report disk full alerts. The new default logging levels should prevent this, with everything now set to the 'Error' level (with the exception of server.memory set to Off). If you've been testing SC7 betas since before the change was made to the default levels, you can either stop the server and delete the log.conf file or else go down the list and manually set them all to Error.
I think we should have some simple form of rotation for systems which don't do this automatically. At least at startup check the disk space and log file size. If it's bigger than some threshold, rename it, create new one. Next time delete the old one before renaming the current etc. Could really be very simple. But seeing users' Windows crash because our logs are GBs large is bad. if size(log) > 100MB { if -e log.0 delete log.0 move log log.0 touch log }
Triode - where in the log code would log rotation best be called? I think we don't need full featured rotation (as provided by eg. Log::Log4perl::JavaMap::RollingFileAppender, but just make sure our logs don't grow endlessly. I could imagine checking file sizes eg. during S::U::Log->init at startup.
Check all *.log files in a given folder for their size. Move to *.log.0 if too big: sub logRotate { my $class = shift; my $dir = shift || Slim::Utils::OSDetect::dirsFor('log'); opendir(DIR, $dir) or return; while ( defined (my $file = readdir(DIR)) ) { next if $file !~ /\.log$/; $file = catdir($dir, $file); my $oldfile = "$file.0"; # max. log size 10MB if (-s $file > 1024 * 1024 * 10) { unlink $oldfile if -e $oldfile; move($file, "$file.0"); } } closedir(DIR); }
Michael - if you are only doing it at startup then I would call this from S::U::Log->init but only call it if we are the server and not in scanner.pl. This will require users to reboot their machines or start/stop the app occasionally but I suspect this is a viable compromise.
How about some minimal configuration ability? No ui necessary, just a setting in server.prefs. A single pref could control whether logs are rotated at all and what the max size in MB should be. 0 = don't rotate, 1 = 1 MB, 1024 = 1GB, etc. Is there a single entry point for all of SC's logging? You could effect a compromise between the overhead required to check the file size every time vs. allowing the file to grow indefinitely by keeping a counter and checking the file size every, say, 1000 logging entries.
change 23709 - add poor man's log rotation (Windows/OSX only) - if log file size > 100MB move to *.log.1, create new file - one old copy is kept on disc - run during log initialization only, which means the log can still grow >100MB if SC isn't restarted Jim - I understand your idea about using prefs to configure this. But I really don't like the idea of one more pref, and even less without UI. I've implemented the log rotation in Slim::Utils::OS. This means you could always change its behaviour by creating your own Slim::Utils::OS::Custom module. This module isn't overwritten during installation. http://wiki.slimdevices.com/index.php/Customizing_SqueezeCenter_using_Slim::Utils::OS::Custom Thanks!
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.