There are some systems that require persistent log data. Currently /var/log is defaulted to a tmpfs mount via the populate-volatiles subsystem. In order to change this, it's required to modify the fs-perms, base-files and initscripts packages. There should be a distribution switch to do this. It may also be appropriate to ensure logrotate behavior is appropriate for disk (persistent) storage vs tmpfs based storage.
I've seen emails about persistent /var/log on Yocto mailing list. I think this feature is important and needs to be done in 1.8. //Chen Qi
Hi Mark, Could you please help review the patches? git://git.openembedded.org/openembedded-core-contrib ChenQi/persistent-var-log http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/persistent-var-log Thanks, Chen Qi
Hi, It looks like the documentation for this bug would be to provide a glossary description for VOLATILE_LOG_DIR variable, which we currently do not document. Aside from documenting this variable and perhaps adding some information else where in the YP doc set showing its use, would there be any other end-user documentation points for this issue? Thanks, Scott
I'll rebase the patches and send them out again.
Hey, Seems weird that we use "" to override "log" and make it persistent and not some more meaningful value for VOLATILE_LOG_DIR. Anyway... to make sure I understand how VOLATILE_LOG_DIR works it basically defaults to "log", which makes the /var/log volatile. If the user wants to save this log and make it persistent, they simply set VOLATILE_LOG_DIR to "". Are there any other user steps they need to take to get this done? Thanks, Scott
Hello Chen, could you please bump the revisions of the recipes you've modified? It's needed to have "smart" updates to work. Thanks
Are you using the PR server? (You should be when doing target package upgrades.) Community policy is not to bump PR numbers manually, except for a few extreme cases. If you are using the PR server, and the PR did not update, please let us know (in a new bug) what the conditions are, as it may be a bug.
Mark, thanks for your reply. We are not using PR service as we can't be 100% sure that the build history is always persisted. I see your point and will bump the PRs of the packages manually in the private branch. Thanks
Any feedback on Comment 3 and Comment 5? For documentation? thanks, Scott
(In reply to comment #9) > Any feedback on Comment 3 and Comment 5? For documentation? > > thanks, > Scott Sorry I didn't notice it. I've changed VOLATILE_LOG_DIR to default to "yes", and we use 'no' to override the default value to make /var/log on target persistent. For documentation, apart from glossary description for VOLATILE_LOG_DIR, a section about 'making /var/log persistent' might be needed. I've seen some users on yocto mailing list requiring this feature, so making it clear in docs might be better. The only problem here is that the patches are not accepted yet. When they are merged I'll change the state of this bug. Regards, Chen Qi
Hi, I updated a couple spots in the ref-manual to deal with this issue: 1 - in the "Image Features" section there is a list of features the user can apply. One being "post-install-logging", which talks about the /var/log directory. I have created a note in that entry mentioning the VOLATILE_LOG_DIR variable as the way to control the persistence of this target directory. See http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#ref-features-image 2 - In the reference manual, I created a new glossary entry for the VOLATILE_LOG_DIR variable. See http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#var-VOLATILE_LOG_DIR Take a look and let me know if these are okay. Thanks, Scott
I updated the "Whiteboard" information. Please let me know if the the doc changes I have made are acceptable. Scott
So you changed the target... does that mean we are good? If so, let me know and I can update the status to RESOLVED and put the doc flag to "done." Thanks, Scott
(In reply to comment #13) > So you changed the target... does that mean we are good? If so, let me know > and I can update the status to RESOLVED and put the doc flag to "done." > > Thanks, > Scott Got it.
Thanks, Setting to RESOLVED and putting the doc flag to "done." Scott
I've no idea why I replied 'got it' ... And this answer led to communication mistake, resulting in this bug changed into a wrong state. I've sent out rebased patches to the mailing list, waiting for review. Sorry for my mistake.
Ok - So I am not sure where we are on the doc changes. You sent out rebased patches for the fix. Do the documentation changes I made in Comment 11 still hold true? Thanks, Scott
(In reply to comment #17) > Ok - So I am not sure where we are on the doc changes. You sent out rebased > patches for the fix. Do the documentation changes I made in Comment 11 > still hold true? > > Thanks, > Scott It's true for my patches. But my patches haven't been merged. If they are merged, then there's no need to change the doc. Regards, Chen Qi
Merged in master. No need for changing the current doc. Sorry for my mistake. Regards, Chen Qi