Which /var/log files can I remove to make space on my drive?

Doga Ozer · 05-07-2021, 04:57 AM

Hi all,

My question is quite general and not quite specific on which log files I'm pointing out to.

But does anybody know how I can determine the old .log.1 or .gz files that are listed in my /var/log directory?

I wanted to backup all of the log files onto a USB partition, but don't know if that's possible on Linux.

Could you perhaps give me suggestions regarding this question I have please?

Thank alot for your support in advance guys!

Kind Regards,

Doga

pan64 · 05-07-2021, 05:14 AM

any .gz can be removed, if you do not need them.

syg00 · 05-07-2021, 05:26 AM

See the manpage for ls - something like "ls -ltr" might be a good start. Start deleting from the top (reverse time ordered).

Doga Ozer · 05-07-2021, 05:38 AM

Quote:

Originally Posted by pan64

any .gz can be removed, if you do not need them.

oh thanks a lot! will definitely do that! appreciate it!

Doga Ozer · 05-07-2021, 05:42 AM

Quote:

Originally Posted by syg00

See the manpage for ls - something like "ls -ltr" might be a good start. Start deleting from the top (reverse time ordered).

Thanks! so according to the list of months top to bottom, from oldest to latest sort of thing?

And for backup, I'm not sure if there's any backup for the logs. Some of the logrotate files are misconfigured so I have changed the rotate from 4 to 1 on /etc/logrotate.conf configuration file, so that it doesn't clog up much space for next time rotating more than 4 log files, if that's what the purpose for that is? that is from what Iv'e understood.

boughtonp · 05-07-2021, 08:38 AM

Log files should not be occupying a great deal of space. If your aim is to free up space you probably want to look elsewhere.

You can confirm their combined size using with "sudo du -sh /var/log" - if they do happen to be taking up excessive space, you should investigate if you have any applications configured with overly verbose/debug log settings that you can revert back to standard levels.

computersavvy · 05-07-2021, 10:34 PM

If the log rotate is misconfigured I would suspect it is because of changes someone has made from the default.

I don't know the reason you are looking at purging log files which happens automatically during a proper log rotate, but suspect it may be due to running out of disk space. The suggestion has already been made to check space used with du.

Maybe the output of a simple "df" would tell us more about what is happening.

Also, if logrotate is not properly rotating logs then the purge that normally happens may not, and if that is the case then the logrotate config needs fixed or the manual purge you are trying to do now will just happen again and again until logrotate is fixed.

rnturn · 05-08-2021, 01:05 AM

Quote:

Originally Posted by Doga Ozer

Hi all,

My question is quite general and not quite specific on which log files I'm pointing out to.

But does anybody know how I can determine the old .log.1 or .gz files that are listed in my /var/log directory?

I wanted to backup all of the log files onto a USB partition, but don't know if that's possible on Linux.

Backing up the log files won't (IMHO) do much good if you're never going to look at them.

Questions I would ask myself:

How quickly will I be responding to incidents that appear in the log files?
Do I even know what to look for in the log files?

If you only find the time to look at the log files on, say, the weekend, and respond to what they contain, you might want to configure logrotate to retain logs (compressed logs if you're not already compressing them) for 10-15 days. That would give you plenty of time to look through logs and deal with what you see in them. Once you get into a habit of looking at the logs, or you've established an automated means of looking through them and generating a report, you can cut down that retention period.
What to look for? Go through a few of the logs and see what looks suspicious: failed root logins and stuff like that. Start by cutting-n-paste some of the strings you see in the messages file and add them to a file named, say, "suspicious_messages.txt" then you could create a short shell script to grep for those strings and email the results to be read. Something like:

Code:

$ sudo grep -f suspicious_messages.txt /var/log/messages | mailx -s "Interesting stuff in messages file" my-account-name

You could set this up in cron to run just before midnight to you get a summary of today's interesting events. (If sudo is always prompting you for a password, you will find it easier to run this command in root's crontab.) If you're worried about missing something important in the last minute or so of the day, you could schedule the command to be run just after midnight though this means a scheduling a simple command won't be as easy as you'll need to picked the correct, by then, compressed log file (see "xz -dc", "bzip2 -dc", etc. to get to the raw log file). Play around with:

Code:

$ date --date='yesterday' +%Y%m%d

and see how that might help you track down the correct compressed log file.

As I mentioned above, log files shouldn't be a cause for disk space problems. Unless your system is under a serious attack, the size of your log files shouldn't be excessively large. But... if disk space has become an issue, please:

Code:

df
sudo su - root -c "cd /; du -s * | sort -n

In both cases, post the results in code tags. The first command will give LQ folks a clue as to your disk/filesystem layout. The second will provide info regarding which directory tree is using the most disk space. (My guess would be NOT /var.)

Cheers...

craigevil · 05-14-2021, 01:33 AM

Or just say the heck with log files and put them in tmpfs.

I use this in my /etc/fstab

Code:

# Added 4 lines to use RAM instead of SSD for temp and log files
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0
tmpfs /var/spool tmpfs defaults,noatime,mode=1777 0 0

jmgibson1981 · 05-14-2021, 09:13 AM

I'd be more concerned with your partition size personally. If it is so small that a few log files cause a problem with space then you need to fix that first. It shouldn't really be an issue on a typical system.

Klen · 05-14-2021, 09:16 AM

Thanks to all for sharing the useful info