Okay, after freeing up some space this morning, this afternoon I see that several machines are at 0% capacity, and I’ve requested connectivity for them.
Now I have a much bigger problem, since I’ve gone from having problems with one machine to having problems with many.
I don’t know how to fix it. I’ll have to go there in person and see what can be done.
If you’re able to, please test the latest nightly. It contains a patch from Suricata which will enable cache management and reduce the amount of disk space used.
Thanks to @stevee for getting this updated hours after Suricata finished the patch. Not only was patching Suricata necessary but also a few other large packages too. The effort was not small. When the next version of Suricata is released this will likely include the patch, but as of now it is yet to be released.
So right now we are ahead of the game, which what you expect from IPFire, right?
Since you’re connected via ssh you can stop IPS, delete its cache then restart IPS again:
Thanks for the replies. It seems that rotating the logs has partially solved the problem, as it was a disaster yesterday, but today it seems to be partially resolved (I’ve followed the steps you mentioned).
A simple question. How can I delete the “/var/log/messages” file in a clean way? The problem is that if it’s 6GB, it’s not so easy to edit it to remove lines. If I delete it and create a new one manually, no entries appear (maybe I’m talking nonsense).
Parsing 6GB log file on APU box to wipe some suricata log lines might take a significant time - and while doing it the services add more and more lines.
The tear and wear of that mSata SSD will be significant.
I had 4 APU boxes in past 12 years and although none of the PCEngines mSata drives died, some of them show some sectors had to be replaced.
I have used mSata from SuperSeed, Phison (with MLC memories) and also some Winjito (?) ones: again, all survived after being used for years as IpFire storage.
But I never had 6GB log file per week, therefore I am wondering if wiping suricata lines in log instead of dumping entire log at once is a good method.
More, I suspect that hostapd Debug variable also generates tons of log lines so that would mean another round to wipe those lines as well: stressing even more the storage.