Suricata logs ignoring rotation settings – RAM disk filling up

[f45tb00t]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Even with Rotate log = Daily and Save logs = 1 set under Services → Intrusion Detection → Administration → Logging, Suricata continues to accumulate not only daily suricata_YYYYMMDD.log files, but also stats.log.* and eve.json.* files in /var/log/suricata/. These are not cleaned up, despite the GUI setting limiting log retention. On systems using a tmpfs RAM disk for /var/log, this causes the partition to fill over time, leading to potential service disruption.

This is critical when minimizing disk writes (e.g. on SSD/NVMe) by offloading logs to RAM. To Reproduce

1. Enable Suricata (IDS/IPS) with logging.
2. Configure Rotate log = Daily, Save logs = 1.
3. Enable /var/log as a RAM disk via System → Settings → Miscellaneous → Disk / Memory Settings.
4. Let the system run several days.
5. Observe that multiple logs (suricata_.log, stats.log., eve.json.*) remain in /var/log/suricata/.
6. Check disk usage of /var/log.

Expected behavior

Only the latest logs (suricata_YYYYMMDD.log, stats.log, eve.json) should remain when “Save logs = 1” is set. Old files should be purged automatically. This is especially necessary for RAM-disk setups where space is limited.

Describe alternatives you considered

• Manually deleting suricata_.log, stats.log., eve.json.* via cron job.
• Disabling Suricata logging completely – not acceptable due to required external logging (e.g. to SIEM).

Relevant log files

ls -lisah
total 122355
  28     1 drwx------   2 root wheel  1.1K Nov 12 13:01 .
   2     2 drwxr-xr-x  19 root wheel  1.9K Nov 12 03:01 ..
7238  6156 -rw-r-----   1 root wheel  6.0M Nov 12 13:43 eve.json
6865 19212 -rw-r-----   1 root wheel   19M Nov 12 00:00 eve.json.0
7459     0 lrwxr-x---   1 root wheel   39B Nov 12 13:01 latest.log -> /var/log/suricata/suricata_20251112.log
7237  2320 -rw-r-----   1 root wheel  2.3M Nov 12 13:43 stats.log
6864  4044 -rw-r-----   1 root wheel  3.9M Nov 12 00:00 stats.log.0
6489  4036 -rw-r-----   1 root wheel  3.9M Nov 11 00:00 stats.log.1
6113  4004 -rw-r-----   1 root wheel  3.9M Nov 10 00:00 stats.log.2
5737  4012 -rw-r-----   1 root wheel  3.9M Nov  9 00:00 stats.log.3
5368  4020 -rw-r-----   1 root wheel  3.9M Nov  8 00:00 stats.log.4
5018  4016 -rw-r-----   1 root wheel  3.9M Nov  7 00:00 stats.log.5
5026  6548 -rw-------   1 root wheel  6.4M Nov  7 00:00 suricata_20251106.log
5372  9216 -rw-------   1 root wheel  9.0M Nov  8 00:00 suricata_20251107.log
5760  8592 -rw-------   1 root wheel  8.4M Nov  8 23:59 suricata_20251108.log
6117  4212 -rw-------   1 root wheel  4.1M Nov 10 00:00 suricata_20251109.log
6488 14112 -rw-------   1 root wheel   14M Nov 11 00:00 suricata_20251110.log
6870 21144 -rw-------   1 root wheel   21M Nov 12 00:00 suricata_20251111.log
7241  6708 -rw-------   1 root wheel  6.5M Nov 12 13:41 suricata_20251112.log

Environment Protectli Vault (model 6640) NICs: Intel i210 series RAM disk enabled for /var/log

[AdSchellevis]

this setting only influences the eve.log, general (sys)log settings can be found in System: Settings: Logging

stats.log.x has a fixed interval of 7 days

https://github.com/opnsense/core/blob/7d5cabed182299c7a642d7f194ec6046275eb4d6/src/opnsense/service/templates/OPNsense/IDS/newsyslog.conf#L3

[f45tb00t]

Hi,

thanks a lot for the quick response. I disabled local logging now completely. I'll come back to you after checking if it fixed it.

[f45tb00t]

Hi again,

I disabled the logging completely. System: Settings: Logging

Unfortunately its still logging in the directory?

root@xxx:/var/log/suricata # ls -lisah
total 60214
  28     1 drwx------   2 root wheel  704B Nov 19 00:00 .
   2     2 drwxr-xr-x  19 root wheel  1.9K Nov 19 03:01 ..
9335  5600 -rw-r-----   1 root wheel  5.5M Nov 19 06:16 eve.json
9044 25064 -rw-r-----   1 root wheel   24M Nov 19 00:00 eve.json.0
7476     0 lrwxr-x---   1 root wheel   39B Nov 12 14:01 latest.log -> /var/log/suricata/suricata_20251112.log
9334  1076 -rw-r-----   1 root wheel  1.0M Nov 19 06:16 stats.log
9043  4076 -rw-r-----   1 root wheel  4.0M Nov 19 00:00 stats.log.0
8752  4072 -rw-r-----   1 root wheel  4.0M Nov 18 00:00 stats.log.1
8461  4072 -rw-r-----   1 root wheel  4.0M Nov 17 00:00 stats.log.2
8169  4076 -rw-r-----   1 root wheel  4.0M Nov 16 00:00 stats.log.3
7878  4080 -rw-r-----   1 root wheel  4.0M Nov 15 00:00 stats.log.4
7586  4052 -rw-r-----   1 root wheel  4.0M Nov 14 00:00 stats.log.5
7237  4044 -rw-r-----   1 root wheel  3.9M Nov 13 00:00 stats.log.6

Ideas how I can prevent this behavior? I don't want any heavy log writing to the nvme. I guess when I change this manually, it will be overwritten with the next update?

And why do you keep the stats.log for the given time range?

[AdSchellevis]

suricata isn't really suitable to be used with ramdisks, the eve log is a requirement, stats we could change to follow the same rules, but that's about it I'm afraid.

[f45tb00t]

@AdSchellevis Thanks for highlighting this. I disabled logging completely. I would wish for a different behavior, especially if someone wants to use ramdisk for logging. I'll close this issue.