Bug #514

SQLite3 BusyException errors with threaded scanner modules

Added by James Lee 10 months ago. Updated 6 months ago.

Status:Closed Start:11/13/2009
Priority:High Due date:
Assigned to:- % Done:

0%
Category:-
Target version:Metasploit 3.4.0
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

Revision 7517
Added by HD Moore 10 months ago

Adds the find/save wrapper back, it seems to help a little, but doesn't solve all cases. See #514

Revision 7703
Added by James Lee 9 months ago

remove the lock that was causing segfaults on 1.9; fixes #513, see #514

History

Updated by HD Moore 10 months ago

The locking code isn't enough to prevent this (still triggers with it re-enabled).

Updated by HD Moore 10 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.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 9 months ago

  • Priority changed from Normal to High

Updated by HD Moore 8 months 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 6 months ago

  • Target version changed from 18 to Metasploit 3.4.0

Also available in: Atom PDF