Bugzilla – Bug 15082
Don't wipe out previous log file(s) at reboot time
Last modified: 2012-03-12 23:50:23 UTC
I'm not sure which component manages log files, but for Radio and Touch the internal log files at /var/log get wiped out when the player is rebooted. That keeps the log files at a minimum, but it does not allow for errors occurring prior to the reboot to be logged. There are at least a couple of hard-to-debug issues like bug 14481 which could really use such a feature. I would suggest some mechanism which doesn't overwrite a small number of older log files, perhaps retaining the previous 2 or 3 log files only.
Can we find a way to keep at least one old log?
The /var/ directory is mounted as ramfs, which means the data in the logs are kept in memory while the system is running. If the system is rebooted the logs are lost because they were kept in memory. I will look into this bug. The challenge is if we persist the data, we have to be concerned with the file-system overhead of write operations. Also we must make sure that the persistence of logs will not fill out the device that is used for persistence.
The log files under /var/log are kept in memory during run time. Because the log files are not persisted on a non-volatile medium they will get lost the next boot-up. There are several reasons for this: 1. The writes to the non-volatile medium are slow, and as such it has a performance hit on the system. 2. The NAND flash and journaling file system that is being used to manage the file-system have a lot of overhead for write operations. This could include potential erase of the NAND flash blocks and garbage collection. 3. The writes to the non-volatile memory could make the file system bigger, and so will impact the boot time. 4. There are always the risk of filling out the flash by log files. For the 7.5 release I do not suggest making changes to keep the log files on the flash. I will provide a list of workaround to have the log files if needed during test/engineering process.
Here is the solution for this problem. ssh to the system and run the following commands and reset the system: # mkdir /media/mylogs # mkdir /media/mylogs/log This will capture the log files on the flash and under the /media/mylogs/log directory. The maximum size of the files before the logs get rotated is 60MB. Whenever you like to switch back to the previous state run the following command: #rm -Rf /media/mylogs notice that this causes all the captured logs to be lost. I would imagine that we can have an option in the UI to facilitate this process, but I am not sure if it has a lot of value.
*** Bug 15900 has been marked as a duplicate of this bug. ***
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!
Chris, I don't consider this bug-report fixed. The solution proposed is a workaround - but if you have a customer that never SSH to the radio after the crash (or a situation where the radio needs to be rebooted to get into a working state) you will still have lost logs. If you always want to tell you customers 'please use this workaround' and unfortunately please wait for the next crash ... then leave it closed. But thats not how customer satisfaction can be achieved in my opinion. At least you should document this workaround (e.g. in the wiki) so other people are aware of it. In this closed bug-report it will get lost and that is bad.
Stefan correctly points out that this is not 'fixed' per se, although the workaround Vahid notes should help most users likely to need this functionality.
Vahid is no longer working for us.