How do you expand /var
-
Hello,
We are running pfsense "2.6.0-RELEASE" and have noticed our /var is out of space. How can I expand /var or make more space in /var?
Thank you for your help!
-
You don't, you find out what's using all the space and delete it. Nothing should use anything approaching that much drive space in pfSense. You have something that is incorrectly using it. Probably logs that are not rotating as expected and that's usually Snort or Suricata.
Steve
-
@stephenw10 I was going to say - wow, my var isn't using anything close to that ;)
on a side note I take it you did an upgrade to 2.6 vs clean - didn't zfs become the new default file system? Notice your still using ufs
-
An unlimited packet capture is my next most likely suspect but that would be in / not /var.
-
Thanks for all the help! We found out it was suricata creating the logs. We were able to uninstall it and remove the logs in the process.
-
Ah, nice!
If you're running Suricata make sire it has log rotation enabled and then there is a total log size limit set.
Steve
-
@vlee There was a version of Suricata that didn't pay attention to limits and rotation. If you've been upgrading it could have been related to that depending on how long they've been sitting there and how old your versions have been. Upgrading will fix it though, and it seems like you've done that. Just make sure you have your limits and rotation on and you should be all set.
-
@vlee I've had the exact same problem with the /var folder. Although I am using tmpfs in RAM to reduce the number of writes to my SSD. Turns out it was Suricata was not pruning the logs like it should. The thing is before upgrading to 22.05 (pfSense Plus) Suricata was working fine and pruning the logs as usual. After the upgrade it wasn't clearing out the logs.
So I uninstalled Suricata which removed the logs and re-installed it. I've enabled the hard limit of 2 gigs for logs so hopefully it'll fix it. If it doesn't then will have to report it as a bug for Suricata.
-
Yes, if you're running RAM disks you have to be very careful with Snort/Suricata. Really neither package is intended to be run with RAM disks.
Steve
-
@stephenw10 I've personally never had an issue with it. It got a 6 gig for /var in RAM.
-
Yes, @stephenw10 is 100% correct. I am the maintainer/developer for both of the IDS/IPS packages, and use of RAM disks is not recommended for either of them. They can log a lot of information very rapidly on a busy network with lots of active rules. That can overwhelm most typical RAM disk setups.
The IDS/IPS packages really do best with spinning hard disks.
-
I will say that a 6GB RAM disk is not typical.
-
@bmeeks Good point. It's got a 500 gig nvme as the boot / os drive. I could throw in an old Samsung 500 gig EVO just for logging. Will take a look at it at the next re-install.
-
@stephenw10 said in How do you expand /var:
I will say that a 6GB RAM disk is not typical.
Yeah, agree that 6GB is certainly not a "typical" RAM disk. But still, some of the Suricata EVE JSON logs can get quite large due to the sheer amount of text info that gets logged there. It does depend, though, on exactly what options the admin has enabled for EVE logging.
-
@darkk said in How do you expand /var:
@bmeeks Good point. It's got a 500 gig nvme as the boot / os drive. I could throw in an old Samsung 500 gig EVO just for logging. Will take a look at it at the next re-install.
One issue you may encounter is that the IDS/IPS packages do not offer a customizable log path option as of now. They default to
/var/log. You can remap that at the OS level, of course. But it's not something you can currently do within the package itself. It is an item on my "wish list" TODO. -
Here's the command we use in TAC to determine the largest folders in /var:
Go to Diagnostics->Command Prompt and copy/pasta the following command:
du -a /var | sort -n -r | head -n 10
