Delete all of /var/log?
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.
Deleting log files is a bad idea (you’ll also need to find every running process that has it’s own log file and «kill -HUP» it, a soft restart that will result in the program recreating any necessary log files). I would strongly advise against deleting log files, rely on utilities like logrotate to manage the contents of /var/log for you automatically (it does stuff like HUP the processes) If I may I’d like to tackle this from a different angle. What problem are you trying to resolve that’s led you to consider this?
10 Answers 10
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.
Well, IMHO deleting all logs can make perfect sense in some cases. For example I want to build a Virtial Machine image to be used for new deployments. Needless to say I would like it to be a really clean system without any logs, histories, caches etc. saved.
Sorry, but looking at three months old log files is archeology. If you collect logs to identify problems, then evaluate them quickly.
@countermode You are never in the mood for nostalgia? Like looking at the 3 month old log files thinking about good ol’ times?
OK, I see the command. How to use it? man logrotate says use it in cron. I suppose with the -f option?
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 ".*\.6$" Try run command without «-delete», to test it.
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.
There are valid reasons to remove log files, IMHO. For instance, you are exporting a virtual machine for use by others, but you don’t want the virtual machine image to contain details of everything that has happened before exporting.
One reason could be, in a scenario where you’re trying to cover the tracks of a system intrusion, although I think this would make a lot of noise.
A reason could also be to simply optimize the space before exporting a virtual machine. This then results in a smaller template file.
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.
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 You can use the option ctime to find old files. for example:
As bindbn explain, first try the find fetch files and after use the option delete 😀
/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.
How to cleanup a /var/log/journal in Linux
You may find your /var/log/journal directory taking up a lot of disk-space.
How do you go about removing, or deleting all these files under var log journal without the system complaining and falling over?
How to tell how much space is being taken?#
You can ask the journalctl command directly, using the —disk-usage argument:
It will report something like this:
Journals take up 3.9G on disk.
Fix: Option 1 (not ideal):#
Go and adjust its config under /etc/systemd/journald.conf , making sure to pay attention to the SystemMaxUse key; set this to something reasonable, like 50M perhaps.
At this point you can force a log rotation by issuing this command:
sudo systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald.service Remember to restart the systemctl process, like this:
sudo systemctl restart systemd-journald.service Fix: Option 2 (not recommended):#
You could always go and delete the offending /var/log/journal/** directory contents, but this is not the recommended way, as the system journal could be writing here, which will probably cause you bigger problems!
Fix: Option 3 (RECOMMENDED!):#
Simply run the following command to cleanup the /var/log/journal directory:
journalctl --vacuum-size=500M This will delete old log files until the directory reaches the threshold size stipulated, in our case, 500M.
It really is that easy to clear or clean up your var log journal!
How can I free space from a massive 39.5GB /var/log/ folder?
Can I delete those files or the entire /var/log folder? Or is that a BIG NO NO in Ubuntu?
7 Answers 7
You must not remove the entire folder but you can remove «Old-Packed» log files without harming your system.
For a typical home user, it’s safe to remove any log file that is compressed and has a .gz extension (as you can see in the picture).
These compressed log files are old logs that are gzipped to reduce storage space, and as an average user, you don’t need them.
find /var/log -type f -name «*.gz» -delete , I removed the compressed files and I only freed around 1 GB of space. Isn’t 50 GB enough for the / dir and the rest of my disk for /home !
My mother’s PC had a kern.log file 21 GB in size. A big kern.log indicates problem in the Linux kernel itself or in something it’s experiencing issues in dealing with. In both cases, it’s recommended to go to the Linux shell terminal and run cat /var/log/kern.log or nano /var/log/kern.log (at the GUI, run something like e.g. gedit /var/log/kern.log or mousepad /var/log/kern.log ) and check what may be the problem. Once you figure out what’s wrong you can then run sudo rm /var/log/kern.log ; sudo telinit 6 in order to delete such (big) file and restart the operating system.
In my case, this will remove only 15.7 MB of 41 files. The real problems here are messages (7.7 GB), user.log (7.7 GB), syslog (4.1 GB) and syslog.1 (3.5 GB). Those four files sum 23 GB. Any way to remove them, or at least reduce their size?
I wouldn’t delete the entire /var/log folder — that will break things.
You could just destroy the logs as @jrg suggests — but unless the things writing to the log files (mostly syslogd) are restarted that won’t actually regain you any disk space, as the files will continue to exist in a deleted state until the filehandles are closed.
Better would be to find out why the logs aren’t being rotated (and later deleted). logrotate is supposed to do this for you, and I suspect it’s not being run each night as it should.
First thing I would do would be:
sudo /etc/cron.daily/logrotate This should rotate the log files (so kern.log becomes kern.log.1); and you can then delete kern.log.1 etc to free up the disk space.
If everything is good so far, the next question is why this isn’t happening automatically. If you turn your computer off at night, make sure you have anacron installed.
I used logrotate -vf /etc/logrotate.conf to manually rotates the logs. Source: linuxnix.com/how-to-rotate-logs-manually-in-linux
DISCLAIMER: I am not an expert on this, use at own risk!
After finding that my /var/log/journal folder was taking several GB, I followed:
You should look at the logs and see what is getting written to them. My guess is ufw/iptables (you are logging all network traffic).
ufw — when you log all packets, you will get large logs. If you are not going to review the logs, turn logging off. If you wish to monitor your network, use snort. Snort will filter through the thousands of packets you receive and alert you to potentially problematic traffic.
My guess it that ufw is the culprit and you are getting a large log in kern.log because you are logging packets there as well.
Sometimes there is a kernel or hardware problem that fills the logs. In that event it is best to fix the problem or file a bug, you will need to review the logs to do that.
If you can not fix the problem, you can configure syslog to as to not fill your logs.
If you provide more details on the problem we can help debug it better.
That’s a very good point. It’s worth finding out what’s clogging up the logs rather than just deleting them. +1.
Deleting /var/log is probably a bad idea, but deleting the individual logfiles should be OK.
On my laptop, with a smallish SSD disk, I set up /var/log (and /tmp and /var/tmp ) as tmpfs mount points, by adding the following lines to /etc/fstab :
temp /tmp tmpfs rw,mode=1777 0 0 vartmp /var/tmp tmpfs rw,mode=1777 0 0 varlog /var/log tmpfs rw,mode=1777 0 0 This means that nothing in those directories survives a reboot. As far as I can tell, this setup works just fine. Of course, I lose the ability to look at old logs to diagnose any problems that might occur, but I consider that a fair tradeoff for the reduced disk usage.
The only problem I’ve had is that some programs (most notably APT) want to write their logs into subdirectories of /var/log and aren’t smart enough to create those directories if they don’t exist. Adding the line mkdir /var/log/apt into /etc/rc.local fixed that particular problem for me; depending on just what software you have installed, you may need to create some other directories too.
(Another possibility would be to create a simple tar archive containing just the directories, and to untar it into /var/log at startup to create all the needed directories and set their permissions all at once.)