[Openvas-discuss] SQL_giveup error
ryan at dopefish.de
Thu Jun 5 19:56:02 CEST 2014
On 6/5/2014 8:29 AM, NopSec wrote:
> On 6/5/14, 9:26 AM, Jan-Oliver Wagner wrote:
>> On Donnerstag, 5. Juni 2014, NopSec wrote:
>>> I reinstalled the latest stable release of OpenVAS-7 (including libs),
>>> but the behavior persists.
>>> "sql_giveup: cannot initiate a transaction within an existing
>>> transaction" found in openvasmd.log
>> I assume this occurs when you start a scan?
>> Have you tried getting performance data from a Slave (menu item
>> Performance under Extras).
>> Another way to learn more about it is to use omp command line tool
>> to control the slave via command line.
> No. I think it occurs when the slaves have messages for the master and
> they try to communicate with it at the same time. The slaves are fine in
> terms of performance. Actually most of the slaves finish in decent
> amount of time. Some other slaves never finish because the communication
> with the master fails with that error.
Our setup here only has 1 master + 2 slaves but I've noticed similar
behavior, although no "sql_giveup...." in my openvasmd.log yet. Not sure
if it is the same problem, I'll just describe it and you can say "yeah"
I first noticed it whenever I tried executing an operation in the web UI
on the master that writes to the task.db while the slaves were running
scans (write actions like adding overrides would seem to hang for ages),
read actions are no problem. The slaves themselves execute the scans
with the expected speed, the slowdown seems to only be on the master.
Not sure if it is relevant, but the scans are all triggered by schedules.
According to strace the openvasmd processes on the master start fighting
for write locks on the tasks.db. Unfortunately I didn't find time to dig
deeper into the problem, but it seems to be the slaves updating the
master tasks.db with the progress of their scans is happening
aggressively (although that probably depends on which kind of scans are
being executed and how fast they are).
I hadn't mentioned the problem earlier because I wanted to gather some
more information, narrow it down and try to figure out something 100%
reproducible first (local scans with ssh credentials executed via a
slave in the same LAN seems to increase the chance of the problem
occurring in my environment).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4240 bytes
Desc: S/MIME Cryptographic Signature
More information about the Openvas-discuss