[SOLVED] /var/log is getting full (currently 100 % used)

[thogarth]

When I start my VM my syslog fills up. I recently made some changes and am looking for support on how to fix this.

 

 - Added M.2 pcie SSD (currently unassigned, but my intent is to move my VM onto it and keep it outside the array)

 - My GPUs switched pcie lanes on the mobo. (moved the one I am using (NVIDIA) to the faster one). The other GPU doesn't really get used (AMD)

 

I have attached my syslog, any help would be greatly appreciated.

garthplex-diagnostics-20210211-1716.zip

Thanks!

[JorgeB]

Diags are just after rebooting, don't see any log spam.

[thogarth]

at the bottom of the syslog it says

 

Feb 11 16:57:30 Garthplex kernel: vfio-pci 0000:01:00.0: BAR 3: can't reserve [mem 0x72000000-0x73ffffff 64bit pref]
### [PREVIOUS LINE REPEATED 1076522 TIMES] ###
Feb 11 16:57:43 Garthplex kernel: vfio-pci 0000:01:00.0: BAR 3: can't reserve [mem 0x

 

I have attached a new diagnostics file just in case

garthplex-diagnostics-20210212-1022.zip

[JorgeB]

Ahh, missed that, you can try this:

 

 

[thogarth]

Thank you! this worked

[lanky8804]

This worked for me also, after hours of trial and error with no luck

[cloudgeek]

crazytrain-diagnostics-20220418-1553.zip Getting a var/log is getting full (53% currently) error when running Fix Problems. Not sure exactly what to look for here and would appreciate some help from the community. Thanks in advance! CT 

Edited April 30, 2022 by cloudgeek

[trurl]

Unrelated but why do you have 200G docker and libvirt .img? 20G docker.img is often enough, maybe a little more depending on how many and which dockers. 200G is a pointless waste of space.

 

And I've never seen any reason to have more than default 1G libvirt.img.

[cloudgeek]

Because I was running out of room. Maybe I have it set up incorrectly and would love any advice you have to offer. 

[cloudgeek]

Would still like to get advice on my original post...though I appreciate the unrelated comments

[trurl]

The usual reason for filling docker.img is an application writing to a path that isn't mapped to host storage.

 

Your earlier diagnostics didn't show a lot of docker.img used at that time, but maybe it has been filling ever since. No good reason to have docker.img 200G and if it is taking more than about 30G then you have something misconfigured.

 

And absolutely no reason to have libvirt.img more than the default 1G.

 

Those earlier diagnostics didn't have very large syslogs, but all syslogs weren't included since they don't go all the way back to bootup. They mostly seemed to be filling with mover logs and entries related to the turbo plugin.

 

Attach new diagnostics to your NEXT post in this thread, along with what you get from the command line with this:

ls -lah /var/log