2.2.3 resolver with problems log verbosity shows 101% full on /var
-
When messing around with resolver earlier 2.2.3 x64, and log verbosity set to 5, when resolver encounters a problem so the logs start filling up, it shows the /var on the dashboard as being at 101%.
Cosmetic.
fwiw.
-
It's been eight years, so I'll repeat myself:
Seeing over 100% in disk usage is due to the way FreeBSD calculates the free space.
From the FreeBSD FAQ:
9.27. How is it possible for a partition to be more than 100% full?
A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the root user. df(1) does not count that space when calculating the Capacity column, so it can exceed 100%. Also, you will notice that the Blocks column is always greater than the sum of the Used and Avail columns, usually by a factor of 8%. -
Did you also configure it to log to a different log file or something? Or increase the size of your log files significantly? The default logs are circular and a fixed size regardless of how many entries are in them (a full log is the same size as a completely empty one), so it can't fill /var/. dotdash's explanation tells why it's >100%, which is normal. But logs exhausting disk space can't be done with a stock system.
-
@cmb:
Did you also configure it to log to a different log file or something?
No, all stock.
Or increase the size of your log files significantly?
No, all stock.
The default logs are circular and a fixed size regardless of how many entries are in them (a full log is the same size as a completely empty one), so it can't fill /var/. dotdash's explanation tells why it's >100%, which is normal. But logs exhausting disk space can't be done with a stock system.
There might be something else attributed to it, from an existing possibly compromised device on the network but I'm still investigating that as other problems namely entire take down of the network occurred at the same time which I've not reported yet, but I'm still investigating as they may be linked or separate or nothing at all except plain ol' user error, but resolver/unbound so far isnt working as expected in some configurations.
Edit. Possibly linked to BootP code.
Edit2. This was a problem with BootP on a device as its all working fine now with the same settings, interesting how it affected the whole network though.
-
If something went really crazy requesting BOOTP or DHCP leases, it could create a really large DHCP leases file, which could exhaust the space in /var/. Can't recall hearing of that happening with IPv4 but it's possible. A couple people have had a similar issue with DHCPv6 and a buggy HP printer that generated hundreds of DHCP6 requests per second in a non-stop loop.
-
@cmb:
If something went really crazy requesting BOOTP or DHCP leases, it could create a really large DHCP leases file, which could exhaust the space in /var/. Can't recall hearing of that happening with IPv4 but it's possible.
No printers on the network, just a couple Win7 boxes, and an ARM box running a linux variant at the time.
I'm in the process of getting more data logging setup so if it occurs again I might be able to provide more info, but one thing I saw in pfsense was alot of references to nics changing from their ip address to 0.0.0.0.
