Big, big problem with /

Hello everyone.

I have several machines that are showing 0% disk space, and I’ve already lost communication with one of them.

Here’s an image of the current disk space status:

I’ve deleted the backups and purged the Squid cache, and now I have:

I’ve tried checking via SSH but I don’t see anything unusual. What else can I check to free up space on /??

The only option I see is to change the machine on these affected computers.

Thanks.

Hi Robert,

just a suspicion: do these machines run with a blue network on Core 199 with ‘hostapd f747ae0’? Could it be that the wireless logs are running full…?

jm2c

Matthias

1 Like

Or if they are running the IPS with quite a few providers then it could also be the suricata cache directory.

https://bugzilla.ipfire.org/show_bug.cgi?id=13926

1 Like

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.

I found this:

[root@bs ~]# find /var/cache/suricata/sgh/ -type f | wc -l
3301
[root@bs ~]#

and:

This is in my opinion, very dramatic problem!!!.

Hi Roberto,

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? :slight_smile:

Since you’re connected via ssh you can stop IPS, delete its cache then restart IPS again:

 /etc/rc.d/init.d/suricata stop

 find /var/cache/suricata/ -type f -atime +7 -delete

 /etc/rc.d/init.d/suricata start

This should free some space.


This might be the answer: Core 199 - Hostapd write exessives logs - #6 by ms

Thanks,
A G

4 Likes

Hello everyone 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).

Cheers!

Hi,

if it would help: I built the patched ‘suricata 8.0.3’ for Core 199 and tested it (thanks @stevee!). Works.

Upgrading is actually quite simple - if someone is interested, drop me a note…

Best

Matthias

1 Like

Hi Matthias,

I have also tested the patch and the cache reduced from 3.6G to 55M, so quite a substantial decrease.

I posted my findings on the bugzilla report

Thanks,
A G

> /var/log/messages

That will be the fastest.

1 Like

so maybe something like this to test if it works.

sed '/suricata/d' /var/log/messages | more

And this to delete anything with suricata in the line:

sed -i '/suricata/d' /var/log/message

Please test the above first.

2 Likes

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.

2 Likes

I have a similar issue with CU 198 , the only available solution is to turn off Suricata on RED.