Bug #514
SQLite3 BusyException errors with threaded scanner modules
| Status: | Closed | Start date: | 11/13/2009 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | Metasploit 3.4.0 | |||
| Resolution: | fixed | Release Note: |
Description
Large scans or nmap imports cause locking errors in Sqlite3.
using http/version against a Google class C:
[*] Error: 74.125.53.65: ActiveRecord::StatementInvalid SQLite3::BusyException: database is locked: INSERT INTO "reports" ("target_id", "entity", "notes", "value", "created", "parent_id", "etype", "source") VALUES(4, 'WMAP', 'Metasploit WMAP Report', '74.125.53.65,80,0', '2009-11-14 00:09:06', 0, 'REPORT', 'WMAP Scanner')
There is some locking code in lib/msf/core/db_objects.rb that looks like it was meant specifically for this bug, but for some reason it is commented out.
Associated revisions
Adds the find/save wrapper back, it seems to help a little, but doesn't solve all cases. See #514
git-svn-id: file:///home/svn/framework3/trunk@7517 4d416f70-5f16-0410-b530-b9f4589650da
History
Updated by HD Moore about 2 years ago
The locking code isn't enough to prevent this (still triggers with it re-enabled).
Updated by HD Moore about 2 years ago
- Subject changed from Locking issues with Sqlite3 to SQLite3 BusyException errors with threaded scanner modules
- Target version changed from Metasploit 3.3 to Metasploit 3.4.0
This isn't a new issue and I dont think we can solve it for 3.3, adding a release note.
Updated by HD Moore about 2 years ago
- Priority changed from Normal to High
Updated by HD Moore about 2 years ago
- Status changed from New to Closed
- Target version changed from Metasploit 3.4.0 to 18
- Resolution set to fixed
Fixed by forcing all database writes through a background thread in sequential order.
Updated by HD Moore almost 2 years ago
- Target version changed from 18 to Metasploit 3.4.0