Bug #514

SQLite3 BusyException errors with threaded scanner modules

Added by James Lee 4 months ago. Updated 12 days ago.

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

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

Revision 7517
Added by HD Moore 4 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 3 months ago

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

History

Updated by HD Moore 4 months ago

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

Updated by HD Moore 4 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 3 months ago

  • Priority changed from Normal to High

Updated by HD Moore 3 months ago

  • Status changed from New to Closed
  • Target version changed from Metasploit 3.4 to 18
  • Resolution set to fixed

Fixed by forcing all database writes through a background thread in sequential order.

Updated by HD Moore 12 days ago

  • Target version changed from 18 to Metasploit 3.4

Also available in: Atom PDF