On 11/19/2010 01:47 PM, Denys Vlasenko wrote:
On Fri, 2010-11-19 at 12:45 +0100, Denys Vlasenko wrote:
This patch removes sqlite database.
Database was used to find dump dirs by [UID:]UUID. This patch uses more natural way: dump dirs are addressed by their directory names.
DB was also used to produce a list of dump dirs. Now it is done by iterating over the /var/spool/abrt directory.
How fast is it?
I created 5000 crashes (by copying the same crash dump dir), then ran:
Ok, even if the speed would not be a problem I still can't get rid of a feeling that storing some crashinfo to a db is a good thing, we can easily achieve this by adding a post-create event which will do it, but then it would be nice to have a complementary event like delete or post-delete to have a possibility to remove the crash info from the db when we delete it. Ideas?
Jirka
# time abrt-cli -lf ... ... ...
UID : 0 UUID : 9352c1ebea321985e6e937a7255c4ddc1b0587b9 Package : coreutils-8.4-9.fc13 Executable : /bin/sleep Crash Time : Fri 19 Nov 2010 11:51:14 AM CET Crash Count: 2 Hostname : dhcp-25-227.brq.redhat.com
real 0m9.816s user 0m0.901s sys 0m0.286s
And finally, DB was also used to find duplicate UUIDs. Now it is done by iterating over the /var/spool/abrt directory.
Crash count, "inform all" and reporting result message are moved from DB field to a file in dump dir.
"Reported" DB field is deleted - if message != "", then this dump was reported.
Patch is run-tested.
Slightly updated patch is attached:
s/CD_COUNT/FILENAME_COUNT/g etc, to make field names consistent
dd_load_text() converts files which contain just "foo\n" to "foo" (that is, trims \n), making it possible, for example, to use "echo 1>inform_all_users" in abrt_event.conf. Mutli-line files are not affected.