Suricata logs ignoring rotation settings – RAM disk filling up

[fastboot]

Hi everyone,

I'm running OPNsense on an NVMe SSD and have intentionally enabled the RAM disk option to minimize write operations to the disk. Since my setup runs 24/7, reducing unnecessary disk writes is important to prolong the SSD's lifespan.

To support this, I've enabled the RAM disk under System → Settings → Miscellaneous and configured logging under
Services → Intrusion Detection → Administration → Logging

Enable syslog alerts - Unchecked
Enable eve syslog output - Checked
Enable eve syslog output - Daily
Save logs - 1

Note: The logs of the FW are usually forwarded via syslog(UDP) to my SIEM


Despite these settings, Suricata continues to generate suricata_YYYYMMDD.log files in /var/log/suricata/, often reaching hundreds of MB in just a few days. These logs are not rotated or deleted, and they accumulate until the RAM disk is full.

Code Select Expand

root@xxx:/var/log/suricata # ls -lisah
total 115555
  28     1 drwx------   2 root wheel  1.4K Nov  4 08:01 .
   2     2 drwxr-xr-x  17 root wheel  1.8K Nov  4 03:01 ..
4320  1284 -rw-r-----   1 root wheel  1.3M Nov  4 08:49 eve.json
3970  4340 -rw-r-----   1 root wheel  4.2M Nov  4 00:00 eve.json.0
4456     0 lrwxr-x---   1 root wheel   39B Nov  4 08:01 latest.log -> /var/log/suricata/suricata_20251104.log
4319  1416 -rw-r-----   1 root wheel  1.4M Nov  4 08:49 stats.log
3969  3852 -rw-r-----   1 root wheel  3.8M Nov  4 00:00 stats.log.0
3619  3848 -rw-r-----   1 root wheel  3.8M Nov  3 00:00 stats.log.1
3269  3840 -rw-r-----   1 root wheel  3.7M Nov  2 00:00 stats.log.2
2919  3788 -rw-r-----   1 root wheel  3.7M Nov  1 00:00 stats.log.3
2569  3700 -rw-r-----   1 root wheel  3.6M Oct 31 00:00 stats.log.4
2218  3664 -rw-r-----   1 root wheel  3.6M Oct 30 00:00 stats.log.5
1866  3632 -rw-r-----   1 root wheel  3.5M Oct 29 00:00 stats.log.6
 558  1592 -rwx------   1 root wheel  1.6M Oct 25 00:00 suricata_20251024.log
 807 11384 -rw-------   1 root wheel   11M Oct 25 23:55 suricata_20251025.log
1158 11160 -rw-------   1 root wheel   11M Oct 26 23:59 suricata_20251026.log
1523 12652 -rw-------   1 root wheel   12M Oct 28 00:00 suricata_20251027.log
1874  9248 -rw-------   1 root wheel  9.0M Oct 29 00:00 suricata_20251028.log
2222  7644 -rw-------   1 root wheel  7.5M Oct 29 23:59 suricata_20251029.log
2577 10564 -rw-------   1 root wheel   10M Oct 31 00:00 suricata_20251030.log
2926  5636 -rw-------   1 root wheel  5.5M Nov  1 00:00 suricata_20251031.log
3276  3116 -rw-------   1 root wheel  3.0M Nov  2 00:00 suricata_20251101.log
3626  3216 -rw-------   1 root wheel  3.1M Nov  3 00:00 suricata_20251102.log
3974  4600 -rw-------   1 root wheel  4.5M Nov  3 23:58 suricata_20251103.log
4326  1376 -rw-------   1 root wheel  1.3M Nov  4 08:49 suricata_20251104.log

This already filled up /var/log, which resides in RAM – defeating the purpose of reducing disk wear and causing stability issues or log loss.

Expected behavior: With "Save logs: 1" and daily rotation, I would expect Suricata to keep only the most recent log (or just eve.json if syslog is enabled), and delete old ones automatically.

Questiosn:
Is this a known bug or expected behavior?
How can I disable or limit Suricata's suricata_*.log files reliably?
Is there an official way to only keep eve.json (for remote logging like to my SIEM) and avoid these legacy-style logs?
Do I need to manually patch suricata.yaml every time?

Any advice or official workaround would be greatly appreciated. Thanks!

Cheers,

fb