Delete all of /var/log?

Question

Can I delete everything in /var/log? Or should I only delete files (recursively) in /var/log but leave folders?

Does anyone have a good rm command line? (My admin skills leave me nervous.)

Note: I am using Debian. I am not sure what version.

Answer 1

Delete all files:

find /var/log -type f -delete

Delete all .gz and rotated file

find /var/log -type f -regex ".*\.gz$"
find /var/log -type f -regex ".*\.[0-9]$"

Try run command without "-delete", to test it.

Answer 2

Instead of deleting the files you should rotate them, e. g. using logrotate.

You never know when you'll actually need the logs from some time ago, so it's better to archive them (up to a reasonable age, e. g. 3 months).

logrotate can compress your old log files so they don't occupy a lot of disk space.

Answer 3

If you delete everything in /var/log, you will most likely end up with tons of error messages in very little time, since there are folders in there which are expected to exist (e.g. exim4, apache2, apt, cups, mysql, samba and more). Plus: there are some services or applications that will not create their log files, if they don't exist. They expect at least an empty file to be present. So the direct answer to your question actually is "Do not do this!!!".

As joschi has pointed out, there is no reason to do this. I have debian servers running that haven't had a single log file deleted in years.

Answer 4

I'm cloning virtual machines from a master. It makes perfect sense to clear the log on the master so that when you boot the clones you won't get the master's log. I did in tcsh:

cd /var/log
foreach ii ( `find . -type f` )
foreach? cp /dev/null $ii
foreach? end

which clears the logs but keeps the files.

Answer 5

Cleaning all logs on a Linux system without deleting the files:

for CLEAN in $(find /var/log/ -type f)
do
    cp /dev/null  $CLEAN
done

---

Samba (/var/www/samba) creates log file-names with ip addresses, you may want to delete them:

for CLEAN in $(find /var/log/samba -type f)
do
    rm -rf $CLEAN
done

Answer 6

You can use the option ctime to find old files... for example:

find -ctime +30

As bindbn explain, first try the find fetch files and after use the option delete :D

Answer 7

/var/log often has permissions of drwxrwxr-x, so is not user writable unless the user is root or belongs to a privileged group. That means new log files cannot be created by non-privileged users.

Applications that expect to log to a point within /var/log will often touch a file into existence somewhere in the /var/log hierarchy during install time (which often occurs with elevated privileges), and will chmod and possibly chown it at that time to permissions appropriate for the unprivileged users who will be using the application.

Apache logs, for example, are usually written to by nobody, who is a user with as few privileges as possible for Apache to get its job done without putting the system at undue risk. But even a more run-of-the-mill application often expects to be able to write to a logfile in /var/log.

So what happens if the logfile, and the path to the logfile don't exist? That's entirely up to the application. Some applications will quietly skip logging. Others will create a lot of warnings. And others will simply bail out. There's no hard-fast rule; it's up to the vigilance of the application developer, as well as how critical the developer considers its ability to log. At best the application will attempt to either write to, or possibly create and then write to a log file at a destination within /var/log, and will find itself unable to do so because it's being run by a user who doesn't have privileges to write into that part of the filesystem.

So the short answer is no, don't delete everything in /var/log -- it breaks the contract users with sufficient privileges to do such things have with the applications that run on their system, and will cause some noise, some silent failure to log, and some all-out breakage.

The appropriate action to take is to set up logrotate with appropriate config files. Typically rotation will be associated with a cron job. Rotation can be interval based, or size based, or both. It's even possible to set up rules that avoid interval based rotation if the logfile is still empty when the interval expires. Rotation can include mailing of logfiles, compression, deletion, shredding, and so on.

The average user wouldn't need to be too concerned about log rotation. Developers would probably want to ensure that logs they use have rotation rules established. In fact, it is likely good manners on the part of developers to set up log rotation at install time for any software-specific logs that software will be creating and writing.

Answer 8

I've implemented a simple cleaner here:

https://github.com/Lin-Buo-Ren/Coward-Unix-Log-Cleaner

It simply:

• Deletes file names with the following logrotated filename patterns under /var/log
  • ^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$
  • ^.*/.+\.old$ (case-insensitive)
• Truncate/Empty files with filenames with the following log filename patterns under /var/log
  • ^.*/.+\.log$ (case-insensitive)

Answer 9

Yes you can.

To delete all logs automatically, edit edit the file .bashrc. In your terminal type any of the below

nano ~/.bashrc - 
leafpad ~/.bashrc - Then save
gedit ~/.bashrc - Then save

For nano click ctl + O to save and ctrl + x to exit edit mode

Add the following to the bottom of the file contents

rm -r /var/log # Deletes logs directory
clear # Clear the terminal

This file is executed every time you log in or launch a terminal instance, thus your logs will always be deleted.

You can also delete them based on time. E.g 3 days ago

find /yourlog/path -mindepth 1 -mtime +3 -delete

• -mindepth 1 means process all files except the command line arguments.
• -mtime +3 will check for the files that were modified 3 days ago.
• -delete will delete them

Answer 10

function goodbyelogs {
find /var/log -type f
}

for i in return $(goodbyelogs);
do sudo cat /dev/null > $i;
echo "Log $i has been cleared";
done

make an executable script and try run as root if sudo isnt working for you