Suricata Service Crashes with "pthread_create() is 11" Error when Processing PCAP with CAPEv2


I’m experiencing an issue where Suricata crashes when processing PCAP files captured from CAPEv2. Whenever I attempt to analyze these PCAPs with Suricata, the suricata.service unexpectedly stops.

  • When it stops, the Suricata service crashes (with the result ‘exit-code’.), making the socket inaccessible by the cape-processor.
  • The “/var/log/suricata/suricata.log” has recorded “Unable to create thread with pthread_create() is 11” error.

I’ve also detailed this issue further on the CAPEv2 GitHub repository: Issue #1717.

Hi, welcome to the community!

What version of Suricata are you using; Suricata 7.0.0 is our latest released version.

Could you share

  • pcap that demonstrates the problem
  • suricata.yaml (so we can see your configuration)
  • command used to launch the Suricata process.

Hi Jeff, Thanks for your swift response:

pcap that demonstrates the problem

Attached as requested. This is just a sample pcap file generated from CAPEv2 network capture.
dump.pcap (21.6 KB)

suricata.yaml (so we can see your configuration)

Attached as requested.
suricata.yaml (82.9 KB)

command used to launch the Suricata process.
There were 3 ways (which all has the same issue) that suricata was used:

  1. Using Suricata command:

cape@capev2-virtual-machine:/opt/CAPEv2$ suricata -c /etc/suricata/suricata.yaml -r /opt/CAPEv2/storage/analyses/1/dump.pcap
i: suricata: This is Suricata version 7.0.0 RELEASE running in USER mode
E: privs: capng_change_id for main thread failed
cape@capev2-virtual-machine:/opt/CAPEv2$ ps aux | grep suricata
cape 4533 99.9 0.9 392808 328192 ? Rs 13:48 0:09 /usr/bin/suricata -D -c /etc/suricata/suricata.yaml --unix-socket

  1. Using CAPEv2 build in python script utility to call suricata service:

capev2@capev2-virtual-machine:/opt/CAPEv2$ sudo -u cape poetry run python utils/ 1
2023-08-29 13:44:52,882 [Task 1] [modules.processing.suricata] WARNING: Failed to get pcap status breaking out of loop: [Errno 104] Connection reset by peer
/opt/CAPEv2/utils/…/lib/cuckoo/common/ FutureWarning: Possible nested set at position 5
exp = re.compile(pattern, re.IGNORECASE)

  1. Using CAPEv2 itself, part of the code contain the calling of suricata command.

cmd = f"{SURICATA_BIN} -c {SURICATA_CONF} -k none -l {self.logs_path} -r {self.pcap_path}"

more information or screenshots (posted by me as well on CAPEv2 issue list): Suricata.service crashes when processing PCAP from samples. · Issue #1717 · kevoreilly/CAPEv2 · GitHub

What version of Suricata are you using?

Suricata 7.0.0, installed via apt.

Additional Info:

  1. Capabilities set for this binary:

cape@capev2-virtual-machine:/getcap /usr/bin/suricata
/usr/bin/suricata cap_sys_admin,cap_sys_nice,cap_sys_resource=ep

  1. It is installed in Ubuntu with the following spec:

CPU: 2 cores from 11th Gen Intel(R) Core™ i9-11900 @ 2.50GHz assigned as vCPU
Disk: 2.9TB

  1. Suricata Log

suricata.log (28.8 KB)

It looks like pthread_create is returning with a no resource available error. This is mostly likely a system level issue, some hardening perhaps, preventing Suricata from creating processes.

One thing to try is disabling limit-noproc. In your suricata.yaml look for the following:

  # if true, prevents process creation from Suricata by calling
  # setrlimit(RLIMIT_NPROC, 0)
  limit-noproc: true

And set limit-noproc to false and retry again. If this helps, we might be running into a conflict against some local system level hardening and our own attempt at hardening.

Either way, it looks like the kernel is preventing Suricata from creating new processes and threads. Suricata itself doesn’t turn this hardening measure on until all the threads are created.

There is also an issue when suricata.yaml contains run-as section that is not empty and you attempt to run Suricata as a non root user. Suricata needs to be started as root to properly change/drop privileges back to that user. This feature is primarily used when monitoring live networks.

If the primary usage is PCAPs, it would probably be best to not have a run-as section, and just start Suricasta as a non root user.

In short, having a run-as section requires starting Suricata as root.

Hi Jason,

Thanks for the reply, both solution that you proposed (changing the limit-noproc and user) works as well in this case.