kernel: pid 37930 (unbound-anchor), uid 59 inumber 562252 on /: filesystem full
-
Unbound wont start and I get the error....
Cant find anything online that resembles a solution. Any ideas?
-
Did you run a "df -h" via console or check your disk stat in the UI? Filesystem full should be pretty obvious but could also point to "inodes" full if there's still space left.
-
Disk is not full. :)
Temporary storage is neither. What does a df -h in the console do?
-
df = diskfree, report free disk space
try it -
Done :)
-
The -h makes it human readable, you could add -i for status of inodes as well but I don't suppose those are full either
-
are you using ram disk perhaps?
-
Not that I know of :)
-
What do the system logs in the gui say? Maybe they will shed more light on what's going on? I've had this problem in the past where, and I can't remember this fully, du and df showed different things. If you have, say, a large log file that gets deleted then it might show as released in df but the filesystem still thinks it is there until the service is restarted. Restarting the box also fixes the issue. You can compare by running "du -h /" and see if it matches the 1.2G you show as used. Here's mine:
[2.4.4-RELEASE][root@]/root: du -h / (lots of entries) 2.7G / [2.4.4-RELEASE][root@]/root: df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufsid/57758f7e2e26ac75 50G 2.7G 44G 6% / devfs 1.0K 1.0K 0B 100% /dev /dev/md0 3.4M 120K 3.0M 4% /var/run devfs 1.0K 1.0K 0B 100% /var/dhcpd/devSee how my 2.7G lines up? That's what you'd be checking.
-
I had to delete the VM and get the backup running. No issues so far.
The header for the post is what is in the GUI log. Nothing else.
-
maybe it was a corrupted filesystem..
try fsck .. next time -
@Cool_Corona Did you try rebooting the VM to see if the issue went away? If it persisted across reboots then it wouldn't have been what I was thinking and it could have been a corrupted file system that needed a good clean out as @kikoman suggested. Did you reinstall with UFS or have you looked at ZFS?
-
@Stewart It survived a reboot. Thats why I used the backup VM. Didnt have time to look into it, since its in a production environment.
-
@Cool_Corona Sounds good. In the future it may just be as simple as stopping the boot cycle and running fsck just to verify the file system. At 6GB I would think it would only take a few seconds. If you haven't done it before read up on it. The process is quite simple and quick. That way you may be able to save yourself some time in the future. Another possibility is that the file system was mounted as read-only instead of read-write. Anyway, glad you got it back up and running.
