Other files you may want to have a look at will be in /var/adm & /var/log (depending on your server).

A good way to determine what is taking up the most space and what can be cleaned up is to first determine what directories are using the most.

For example, if you have a /var partition and want to calculate which directories are using the most space, do this:

# cd /var
# du -skx * : sort -n

It will show you each directory directly under /var and the amount of space it is using in kilobutes. You can then use that info to determine if it is indeed log files in /var/log. Or maybe your mail server has a lot of extra queue files that are not getting processed and they are taking up your disk space… stuff like that.

Another thing to look for is extraneous core files from crashed processes that you do not need for debugging purposes. Usually they’re not that big but for bigger apps (database, etc) they can get quite large.

You can do one of two commands to find core files:

* traditional find command – this is more resource intensive if you have a large amount of data, but is the “best” because it works on EVERY Unix server

# find / -name core -print

* locate, which should work on most Linux machines but may not tell you about recent core files:

# locate core

find . -name *.log : xargs rm
was the way I was going to go, but then it said
-bash: /usr/bin/find: Argument list too long
rm: too few arguments

I also tried
mv *.log /dev/null
which generated a similar error.

Silly me, I thought it was rm that was complaining when it was in fact bash!!
Obviously the string that bash generates by expanding wildcard ‘*.log’ is too long for it to pass to any command.
Just like Juri said it is a shell limitation.I have looked, but havent seen any options or shell variables that would let me up this limit.

So I escaped the wildcard and let ‘find’ handle it by
find . -name ‘*.log’ : xargs rm
which did it.