Bug #1411
closedSuricata generates huge load when nfq_create_queue failed
Description
It's a misconfiguration but i guess it should be handled in a better way.
If you have one suricata instance running on QUEUE 0 (with -q 0) or any other process (snort on QUEUE 0 for example) and start another instance of suricata also with -q 0 the following correct error occurs:
<Error> - [ERRCODE: SC_ERR_NFQ_CREATE_QUEUE(72)] - nfq_create_queue failed
But then the second suricata is still processing and starting but generating 100% cpu load (strace shows mass nanosleep).
I would suggest to quit suricata in this error case (easy fix) or implement some sort of mode that periodically checks if the queue is available (kinda complicated) and attaches to the queue, but until then it waits with normal sleep instead of nanosleep.
Updated by Victor Julien over 9 years ago
- Target version changed from 2.0.8 to 2.0.9
Updated by Victor Julien about 9 years ago
- Target version changed from 2.0.9 to TBD
Updated by Andreas Herz almost 9 years ago
That's present with 3.0 as well, any votes against quitting suricata in that case (nfq_create_queue failed)?
Updated by Victor Julien almost 9 years ago
I think quitting is fine.
In some other cases, like pcap when the interface is down, we enter a loop to retry opening the iface where sleep inbetween. Perhaps something like this could make sense here?
Updated by Andreas Herz almost 9 years ago
Victor Julien wrote:
I think quitting is fine.
I may be wrong but we would quit if we handle the return value correct :)
We start the relevant section with:
int r = NFQInitThread(ntv, (max_pending_packets * NFQ_BURST_FACTOR));
Which results in
return TM_ECODE_FAILED
But we check for r < 0 to quit although TM_ECODE_FAILED is 1. So i would just change it to > 0 or even !=0 since this would be every case unless we get TM_ECODE_OK.
Any objections or did i miss something in my thoughts?
In some other cases, like pcap when the interface is down, we enter a loop to retry opening the iface where sleep inbetween. Perhaps something like this could make sense here?
So you would also suggest waiting for the NFQ to become available again and attach but with a bigger sleep?
Updated by Victor Julien almost 9 years ago
Sounds like a simple fix indeed.
Wrt entering a loop, would that be useful you think?
Updated by Andreas Herz almost 9 years ago
Well depends on what you want to have, either quit and let the "outside" handle the error or just loop but then is the question when to end and how much resources should be "wasted".
I would prefer the quit since it's some sort of error and you still have to fix it before suricata can work again properly.
I will do a PR with the fixed version and would say we wait until anyone needs the loop solution :)
Updated by Andreas Herz over 8 years ago
- Status changed from New to Closed
- Target version changed from TBD to 3.0.1RC1