One of my older hosting servers runs into space issues constantly. And most of the time it's a 24 GB log file (
error_log) from a really old Joomla-based website.
Why it gets so huge? Well, when I
tail the logfile, I see messages about functions being deprecated in PHP, warnings, notices and a whole lot more literally racing by. I'm not sure if Joomla changed in recent years, but most of the code-base is a great example of how PHP applications should not be build. Part of the problem in this particular case is that the system is hacked together and no one wants to update it. I'd argue another short-coming of the system since extensions actually require you to edit files and upgrade paths are not very clear.
Since it's a friend who's running the website, I haven't been very pressing on him to move to something more updated.
No space left on device
The usual quick fix is:
rm error_log && touch error_log && chown www:www error_log
Nice, and easy.
The only problem is that the system will usually take a while until recognizes that there is free space indeed.
FreeBSD recommends soft-updates — they have a lot of advantages. The only disadvantage is that e.g. the inodes will claim the address space until the write is completed. In case of a log file, this is usually when the process writing it is shut down.
Here's a system with soft-updates enabled:
server# mount /dev/ad8s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad8s1e on /tmp (ufs, local, soft-updates) /dev/ad8s1g on /usr (ufs, local, soft-updates) /dev/ad8s1d on /var (ufs, local, soft-updates) /dev/ad8s1f on /web (ufs, local, soft-updates) procfs on /proc (procfs, local)
The fix to making the system recognize the space is simple:
- Restart your webserver, e.g.:
- Or run
I hope I never ever forget this. Ever.