[Openvas-discuss] SQL_giveup error

NopSec info at nopsec.com
Thu Jun 5 20:18:39 CEST 2014


On 6/5/14, 1:56 PM, Ryan Schulze wrote:
> 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).
>
> Ryan
>
>
>
>
>
> _______________________________________________
> Openvas-discuss mailing list
> Openvas-discuss at wald.intevation.org
> https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
Thanks Ryan. That is exactly the behavior that is happening. It is
usually associated with large network doing authenticated scans.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wald.intevation.org/pipermail/openvas-discuss/attachments/20140605/5c12bf39/attachment.html>


More information about the Openvas-discuss mailing list