some of you may know me already as a rather old ipfire user.
As I’m running ipfire with GREEN, RED and BLUE interfaces by hostapd on a N3160 platform for several years now without any severe problems.
Which changed with the core 199 upgrade dramatically. The first issue, I run into, was, that /var/log/messages suddenly run out of disk space and so blocked even the root login via putty. Looking after by an external tool I found messages file grown to 3.4 G(!)Bytes without being gzipped inbetween.
That I got twice, before I read Michaels suggestion to fix one of the config files, what I was able to do on a clean installation, before the overwhelming logging used all my flash space again.
But even if Michaels Blog on core 200 admitted, that there were unintended log entries by hostapd, there are now still lots of other logs(?) wasting disk space so much, that I find used storage space increased by some 3MB every hour.
Which is not acceptable for me, as this will let run any flash drive upto 32 GB out of space within one year. Or maybe I’d better say: It urges me to look after strorage usage every half year and do a new install, if space left is not reliable no more.
I mean, I knew ipfire to work reliably for years and not wasting storage yet, and so don’t understand, why I need to look after it so often now.
Since last fresh 199 installation, I did at 02/08/2026 at 2 am and updatet to 200 at once, /var/log/messages grew up to some 160KB, whereas /var/log/suricata/stats.log already reached some 280MB and while I’m writing this, growing every time I look after, not only a few but tens to hundreds of KB.
What the heck is going on there? And how can I keep suricata from filling my storage?
It has already been discussed in other posts and a bug report has been raised and the fix from Suricata has been applied to CU200 and is available for Testing. https://bugzilla.ipfire.org/show_bug.cgi?id=13926
@bbitsch I’m using a 8GB SSD, so not so far away from yours. But I’m sure, even a 16GB SSD would have been filled up to its extents within days by the overwhelming debug info of hostapd delivered with core update 199. Maybe with the uninhibited logging of suricata by core update 200 it may last some longer, say couple of months.
But I use ipfire since ipcop times and never ever had to worry about my SSD space. And I just wish not to have to do in the future.
@bonnietwin I think, I already mentioned that I updatet to 200 and have my problem with suricata exactly at this level.
@pscar13 I entered the three commands on PUTty, but still have suricata stats.log growing 7KB every 2 seconds. Ok, this is not so much as before, but still to much. I mean, that is over 250MB per hour. And as I did not see any automatic gzipping yet, suricate log will use all my free SSD space with not even two weeks.
/irony mode on/ Ok, it’s still more than the two days, that hostapd debug mode needed to kill my ipfire. /irony mode off/
Sorry, folks, but I’m not really confident no more, after my second ARM based ipfire, quited its job, too, after I upgraded it to 199 and then to 200. I still must look after its SD card, but I fear, it’s the same thing as with my N3160…
Those commands just clear down your logs. You’ll want to run them daily (cron/fcron) until CU200 is released, unless you run the test version of CU200.
An occasional info: hostapd seems to be well now, only suricata’s stats.log still grows by some 100MB per day, without being gzipped inbetween at all. Ok, if this continues, I need to worry about free storage, but not again within two days like with overwhelming hostadp log entries. I now have some weeks to find or get a fix…
It will prune all cache entries that are older than 7 days.
If you are getting new cache entries at 100MB per day, maybe look at how many rules you have selected and see if they are all necessary for your use case.
My cache grows by less than 100MB per week but i only have Emerging Threats selected and i have selected around 9 of their rulesets.
The bug 13926 concerned the cache /var/cache/suricata/sgh/
It’s unrelated.
It’s true that /var/log/suricata/stats.log is updated every 8 seconds !
Perhaps this is a setting that needs adjusting ?
in /etc/suricata/suricata.yaml
# Global stats configuration
stats:
enabled: yes
# The interval field (in seconds) controls the interval at
# which stats are updated in the log.
interval: 8
Hmm, After suricata seems to be on board since 2.23 CU 131, I just wonder, why I did not notice its really big log not yet… Or was it just accidentally, in the context of hostadp’s excessiv logging, that I got to be observing?
