Bug #514
SQLite3 BusyException errors with threaded scanner modules
| Status: | Closed | Start: | 11/13/2009 | |
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assigned to: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | Metasploit 3.3.4 | |||
| Resolution: | fixed |
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
History
Updated by HD Moore 3 months ago
The locking code isn't enough to prevent this (still triggers with it re-enabled).
Updated by HD Moore 3 months 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
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 1 month ago
- Status changed from New to Closed
- Target version changed from Metasploit 3.4 to Metasploit 3.3.4
- Resolution set to fixed
Fixed by forcing all database writes through a background thread in sequential order.