Task #3191
closed
access to crashlog dump files
Added by Luboš Luňák about 4 years ago.
Updated about 4 years ago.
Description
I cannot reopen https://redmine.documentfoundation.org/issues/3189 , so I'm posting a new issue:
Please give me access in some way also to the actual crasgreport dump files, which according to the crashsubmit_uploadedcrash database should be in /srv/crashreport/temp, which is restricted. It would be much simpler for me to extract the information in an automated way from the files rather than trying to reconstruct it semi-manually from the partial information present in the database (e.g. I'm unable to find any easy-to-use mapping table from CPU family/model information to features or even CPU names and would probably have to create it myself, but .dmp files include /proc/cpuinfo dumps with all the information).
As the name suggests this is a temporary directory: .dmp files files are removed after a given retention period (about a month AFAICT). Also, what kind of analysis are you trying to conduct? Just do some metric collections over the 1 month worth of dumps, or something long term? Blindly traversing the files to dump /proc/cpuinfo content or the windows equivalent is not gonna fly unless you need to do that only once. (And even so there is a lot of data in there, you'd need to make sure to lower the I/O scheduling priority to avoid starving other processes on the box.) If the data inserted to the database is not enough and you need to collect metrics for a much longer period, then this should be done using the spooler interface as the dump comes in, just like for minidump_stackwalk runs.
A month's worth of dump files should be a representative enough sample. I want to do a one-time analysis of the HW used to run LO (CPU features most notably, such % of machines not capable of SSE2, SSE3, etc.). And this information is not easily available in the database, I'd need to tediously semi-manually gather this information based on the CPU family/model line (now that I think of it I'm not sure if a dump from Windows includes this information, but I'm unable to create one locally, so I can't check here).
And my plan was actually to download all the dump data so that I can play with it here without putting too much load on the remote machine. I estimate that to be ~1-2GiB of compressed data, which is not that little, but then I can download it slowly over the weekend. But if you have a better idea on how to collect the information I want, I can try that too. If the server can be modified to extract this information into the database and then extract it also for the month's backlog of dump files, that'd be fine with me too.
Then let me produce the archive for you: /tmp/crashdumps-tmp.tar.xz and let me know when I can remove it.
If the server can be modified to extract this information into the database and then extract it also for the month's backlog of dump files, that'd be fine with me too.
That'd be the most elegant solution but also require dev work and probable need to be implemented by moggi.
I have downloaded the file, thank you.
- Status changed from New to Closed
I have downloaded the file, thank you.
Great, removing it and closing the issue.
Also available in: Atom
PDF