Disk is 104% full
-
du -hd1 /varThere. Run the some command for the directory under the biggest one you have found above. Find what's using your disk space. Delete it. Stop using such package or limit the logging/caching/god knows what properly. Or get a properly sized HDD for the task.
-
I had the same problem and after a couple of days with out doing anything it went back down by itself
-
du -hd1 /varThere. Run the some command for the directory under the biggest one you have found above. Find what's using your disk space. Delete it. Stop using such package or limit the logging/caching/god knows what properly. Or get a properly sized HDD for the task.
I run this command and this is what it displays :
92K /var/etc
4.0K /var/yp
44K /var/unbound
12K /var/tmp
28K /var/spool
4.0K /var/rwho
124K /var/run
4.0K /var/preserve
4.0K /var/msgs
4.0K /var/mail
12K /var/log
4.0K /var/heimdal
4.0K /var/games
4.0K /var/empty
17M /var/db
8.0K /var/cron
8.0K /var/crash
4.0K /var/cache
4.0K /var/backups
4.0K /var/authpf
12K /var/audit
12K /var/at
4.0K /var/account
52K /var/installer_logs
3.3M /var/dhcpd
1.2M /var/squid
4.0K /var/lightsquid
32K /var/squidGuard
22M /var -
I have no idea what's /dev/ufsid/558d3d40eba9a34e - if you hacked pfSense to mount another disk completely outside of existing directory structure, you need to pick up the pieces.
-
I have no idea what's /dev/ufsid/558d3d40eba9a34e - if you hacked pfSense to mount another disk completely outside of existing directory structure, you need to pick up the pieces.
It's a reference to the disk containing the root file system using ufsid, which you can switch to using /usr/local/sbin/ufslabels.sh
The big advantage of this approach is that changes to controller names don't leave your system unbootable.
It's clear that the OP's high disk usage is in /var/db from the output posted, so the next step is du -hd1 /var/db
-
with du -hd1 /var/db the result is :
4.6M /var/db/rrd
616K /var/db/pbi
4.0K /var/db/portsnap
4.0K /var/db/ports
4.0K /var/db/pkg
4.0K /var/db/ipf
4.0K /var/db/hyperv
4.0K /var/db/freebsd-update
4.0K /var/db/entropy
4.0K /var/db/pingstatus
4.0K /var/db/pingmsstatus
4.0K /var/db/cpelements
11M /var/db/ntop
4.0K /var/db/squidGuard
17M /var/db -
I read your original output twice, came to the correct conclusion, then came to an incorrect conclusion and posted based on it. I mixed up M and G. /var is not the problem - it's only a few tens of megabytes. You're looking for something that uses gigabytes.
Try du -hd1 /
I have a suspicion that full backups in /root might be the problem. What does ls -l /root/*.tgz show?
-
Look. There's a GUI button to wipe Squid cache. Why on earth don't you use it?! Where did you place the Squid cache? How many disks you have on your pfSense box?
-
Where is that button? I can't find it. Squid is placed under /var/squid/cache. I have one disk.
-
It's very surprisingly located on the 'Local Cache' tab…
-
I don't have this button
-
Yeah, when you are using Squid 2.7, you don't and won't have any such button. Noone maintains that package. No good reason to use it either. Dead crap.
-
David_W is right. This doesn't look like a Squid cache problem. Run the command he suggests (du -hd1 /) and see what the output shows. You're looking for a folder somewhere containing gigs of data.
-
I run it;=. It displays :
4.0K /.snap
17M /boot
904K /bin
12K /conf.default
3.0K /dev
18M /etc
56K /home
14M /kernels
264K /libexec
7.9M /lib
405M /root
3.4M /sbin
31G /usr
50M /var
248K /tmp
4.0K /mnt
5.9M /cf
4.0K /media
4.0K /proc
4.0K /rescue
4.0K /scripts
4.0K /tank
184K /lost+found
32G / -
31G /usr
There's your problem. Run 'du -hd1 /usr' to see what subdirectory under there is taking up all the space and address the issue accordingly.
-
When I run it, the result is :
31G ./pbi
4.0K ./obj
460K ./libexec
16K ./lib32
38M ./share
30M ./lib
5.3M ./bin
5.5M ./sbin
155M ./local
31G . -
Keep going. So what folder under '/usr/pbi' is full? (Hint: run 'du -hd1 /usr/pbi'). My guess is that you have a load of Squidguard cache info sitting in there.
-
I run it :
12K ./etc
28K ./share
4.0K ./rc.d
16K ./bin
8.0K ./man
4.0K ./.hashdir
211M ./freeradius-i386
73M ./squid-i386
399M ./ntopng-i386
30G ./sarg-i386
41M ./bandwidthd-i386
31G .then I run du -hd1/sarg-i386/ and the result is :
30G ./local
4.0K ./rc.d
4.0K ./pbimeta
4.0K ./virtbase
4.0K ./linux
4.0K ./run
12K ./pbiconf
36K ./bin
30G .
then I run du -hd1/sarg-i386/local and the result is :
8.7M ./sbin
6.0M ./share
1.1M ./etc
2.2M ./include
14M ./lib
56K ./libdata
2.1M ./bin
816K ./info
30G ./sarg-reports
30G . -
Yeah. So, what's exactly your question? Delete the Sarg cruft. How on earth have you managed to accumulate 30 gigs of reports in 3 months? Are you running that nonsense every 5 minutes or WTF?
-
Thnaks to all. I deleted all the sarg reports and now I have a disk with 5% use.