Abandoned Suripcap directories

[alan-lafleur]

Version

2.4.211

Installation Method

Security Onion ISO image

Description

other (please provide detail below)

Installation Type

Distributed

Location

on-prem with Internet access

Hardware Specs

Exceeds minimum requirements

CPU

20 physical, 80 logical

RAM

132 Gig

Storage for /

293G

Storage for /nsm

1.5T

Network Traffic Collection

span port

Network Traffic Speeds

Less than 1Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

I had increased the threads for Suricata up to 78 at one point as a test, then backed down to 48 which is what I have currently. Looking in /nsm/suripcap, I see folders 49-78 in there and appear to no longer be written to based on the date.
Will these folders eventually be removed automatically or can I go in and manually delete them without fear of corruption?

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[cm-ops]

What is your maxsize set to? https://docs.securityonion.net/en/2.4/suricata.html#pcap-configuration-options That setting is for PCAP retention.

Do you need to query for PCAP during the time frame of the PCAP? If not you could remove them.

[alan-lafleur]

Thanks for responding. It looks like each allocated thread creates a directory in suripcap, and each directory is numbered corresponding to the thread number. Increasing the thread count caused these new directories to be created and written to. No problem, makes sense so far. However, when decreasing the thread count it doesn't appear there is any mechanism to go in and delete the corresponding directories. E.g. in my case the 49-78 directories have not been written to for a week, but my pcap retention right now is saying it is 3 days so I would think those directories would have been removed by the system if they were ever going to be.
Anyway, I went ahead and removed them manually.