[Openvas-discuss] SQL_giveup error

Ryan Schulze 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" 
or "nope".

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...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4240 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.wald.intevation.org/pipermail/openvas-discuss/attachments/20140605/d783a0ce/attachment.p7s>

More information about the Openvas-discuss mailing list