Suricata

That's present with 3.0 as well, any votes against quitting suricata in that case (nfq_create_queue failed)?

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?

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?

Sounds like a simple fix indeed.

Wrt entering a loop, would that be useful you think?

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 :)