How to keep root partition from ballooning up?

[Paul Adasiak]

How can I ensure that the files /var/log/messages.0, /var/log/kern.log.0, and /var/log/syslog.0 do not balloon out of control and take up my hard drive?

I recently booted up (using SimplyMEPIS 6.5), and after the login, when the KDE splash screen would usually appear, I was given the message:

Xsession: warning: unable to write to /tmp; X session may exit with an error

I clicked "okay" -- then was taken back to the login, where the same thing happened several times. For some reason, the system after a while gave me this message:

There was an error setting up inter-process communications for KDE. The message returned by the system was:
Could not read network connection list.
/home/shared/.DCOPserver_desktop__0
Please check that the "dcopserver" program is running!

A little Web-checking suggested that my hard drive had filled up, and the output of

df -h

(when I logged in with the terminal, as root) showed that /dev/hdd4 (my MEPIS partition) was 100% used.

A couple of people suggested (for others with a similar problem) that one answer was to clean the .deb packages with

apt-get clean

and even

apt-get autoclean

This worked enough right away for me to use the GUI, but the next output of df -h (I ran it right away) showed that /dev/hdd4 was still 94% full -- so I was worried that my hard drive might fill up unexpectedly. A little poking around showed that three files in /var/log/ -- messages.0, kern.log.0, and syslog.0 -- were the leading culprits, each occupying 1.36 GB.

One or two logins (and complete powerings-down) later, none of those three files is above 776 K, and /dev/hdd4 is only 40% full -- and, since it's an 8-gig partition, that doesn't worry me a bit. What worries me is: how do I make sure something like this doesn't happen in the future? Have I already done it by running clean and autoclean? (Also, they don't show up in my list of installed packages, so how do I know that they're "installed" and that they'll do their job in the future?)

--Paul

[Cabhan]

So there's a utility called logrotate that allows you to set certain parameters for your logs, to prevent this from happening. For instance, you could delete logs that were old, or any such thing.

Run "man logrotate" to see some documentation on this program.

[TheBigPhish]

a little thing you can try is to also split off partitions like /var & /tmp, (and in some server based instances /var/log) to their own partitions so that runaway log files don't bork your installation like they did.

The full partition will definately do what yours did, as you can see. Without seeing the log files contents, i can't tell you why they got so big. Rotating log files is great, but if you don't have limits set on the max log file size, you will just get runaway sizes w/o constraints. Many errors in a short timeframe, like a cron job runaway could do this, and it stinks to try to troubleshoot that if you don't know what is going on.

It is very obvious that you have something awry, with logfiles that size...try to find out what is filling them up.

If you spawn /var & /tmp onto their own partitions (I use a gig for each minimum on my servers), you will still have the / space to allow things like X & root processes to run...albeit with some trouble. You will atleast get a partially usable (and much easier to diagnose system) with a completely full /var or /tmp, as opposed to the near useless brick of a box with a completely full / partition.

[oz]

How can I ensure that the files /var/log/messages.0, /var/log/kern.log.0, and /var/log/syslog.0 do not balloon out of control and take up my hard drive?

I'm not running a production server or anything, so I generally scan the log files every few months looking for anything that doesn't look quite right, or for anything suspicious. If all looks well, and the machine seems to be running properly, I delete the log files.