"Personal thoughts, ramblings, and nonsense from Drew, himself."
This post was written on July 23, 2007 at, or around 12:22 am by Drew. This post is composed of 1,216 words from the English language and currently has 19 comments to its name. Additionally, this article is tagged under CentOS, Debian, Programming, Shell Scripting, Sys Admin, Tips, UNIX/Linux, Walkthrough and you can trackback to this article using this link. This post was last updated on Apr 4, 2008. Enough talk, carry on.
Sometimes, as a Systems Administrator, or SysAdmin, there are times we need to clear out the log files, without actually deleting them. As a smart Sys Admin, you normally wouldn’t need to do this, but as I am currently involved in supporting customers and their Linux machines, I run into some pretty neat stuff (neat as in special). I’ve had a few issues where someone actually runs out of disk space on / (root filesystem) due to the /var/log directory being full.
First off, you might run the df command only to realize that, maybe, you have used 97% of the partition up, in this case / (root filesystem). More times than not, this is usually due to your /var/log directory. Make sure though, I’m presuming that you already know that your /var/log directory is full. To find out what is taking up the most space (you should already know why, and thus you are viewing this possibly because you are having issues with a full filesystem), you would need to run the df command.
The df command is a great way of seeing how much space is being used and/or remaining per partition (mount point, actually), but now we need to find out what files are taking up the most space, for reference. We are still going to wipe the whole /var/log directory, just for the fact that it does work and it can be a good life saver in knowing how to clear out your log files without deleting them. Back on topic, though, as we want to find out (for reference) what files are taking up the majority of the space, we will need to use the du command. The du command stands for Disk Usage and it can be very useful in telling us exactly what files are taking up the most space, and where they are located. So, by now, you already know that your /var/log directory is practically full, and now you want to find what files are taking up all that space. We shall run the following command:
BASH
[root@server ]# du /var/log/* -s | sort -rn | head
As you can already tell, this is not just the du command. We are using three programs (all of which are on a default install of Linux): du, sort, and head. I’ll explain the command. First, we run du /var/log/* -s, which initiates the du command and searches everything in /var/log and each argument is then summarize (-s). Then the output of the du command becomes the input of the sort command. Using sort, we reverse the output (-r) and numerically sort it (-n). From there, we then take the output from the sort command and then that becomes the input for the head command. Remember how we reversed the sort order? That’s where the head command comes in handy. When we reversed the output, by sorting in reverse order, the large files that du found would have been at the bottom, but because we reversed the output, they are now going to be at the top. If you need more results, just add a -n to the head command (e.g.: head -30) which would show the top 30 biggest files (if using with the whole du, sort, head command above).
Once you have the output, that’s where you could clear out those particular log files. You can do that with the cat command. You would “cat” /dev/null (nothing) and redirect the value (again, nothing) to that particular log file, in which, it would overwrite the log file with nothing, so your log file has theoretically been cleared, but you did not delete it.
An example of just clearing a single log file with the cat command, would be as follows:
BASH
cat /dev/null > /var/log/btmp
That’s it! Currently the /var/log/btmp file was 23MB (due to not changing the default SSH port; which is offtopic), and after running the previous command, the file is now 0 bytes. Now, what if there was alot of files in the /var/log directory, and you needed to just clear all the log files out of the system? With a little work, you can. Before I actually show you how to do this, you’re probably wondering: “Why not just delete the log files?”. Good question, cause I used to have the same question. Your /var/log directory holds a good amount of the log files for every daemon that is running on your system. Just a side note, /var/log is what most daemons use for their log files, but you should check the daemon (if you want), as it might have a custom place for writing its own logs. Okay, to answer the main question, you should not just go deleting log files, because certain daemons that are currently running are using these log files and can either crash (sometimes) certain daemons and/or cause them to fail to start back up, even on a reboot. Sometimes you would have to manually re-create the certain log file the system cannot find (usually using the touch command. Now, I’ve gone through doing the hard part (figuring out how to do it), and you just have to run the command. Here’s the command (will explain):
BASH
find /var/log/ -name '*.*' -not \( -type d \) -print0 | xargs -0i sh -c "cat /dev/null > "{}""
I know, I know. Like I said, I’ll explain. Yes, that is two double quotes at the end. Put this in exactly as shown; I have not tested what will happen if this is not put in exactly, so if it decides to remove any data you didn’t want it to, I’m not liable. Alright, now for the explaination. The find command is executed with options to look into the directory /var/log and find all files (wild carded for any file it comes across), but it will exclude any directories that it finds and will search within them and clear out the files in there. The reason we want this is because if we did not tell it to “match” the directories, it would error out and would not complete the clearing out of the files. The find command then prints out and becomes the input of the xargs program and states that as long as the file is not equal to 0 (empty file) to execute the cat /dev/null and redirect the output of /dev/null (which is nothing) to all files it comes across. This in turn will wipe out all the files’ contents within the /var/log directory, but will keep the files there.
I just want to say, this is not the best solution for log file administration, but it can definitely get you out of a bind if log file administration isn’t extremely important (if its a personal server, or if it is low profile and isn’t High Availability, etc). I would definitely look for an alternative way to administer your log files (I use logrotate), but again, in this case, you should be able to use this solution just fine. If you run into any issues or just have some questions, please don’t hesitate to post them so we can all discuss.
I’m waiting for your next post(s). :D
I’ve been swamped at work. You should see my “drafts” section, it’s crazy. I have plenty of stuff to post and I already have ideas for two more articles that I’m starting to put on paper. Sorry for the delay, however, I’ll have more stuff soon.
Regards,
Drew
heh… I was joking… I know you’ve been busy. :-)
Yeah same here.
Lots of posts, little time.
Great article. I really enjoy reading it. Very useful and insightful. Waiting for more articles from you.
Thanks. I’ve got a question, though: how to erase just lines with specific infos, i.e. lines that contain infos about app “XY”, not to empty logs completely?
Great article. I really enjoy reading it. Very useful and insightful. Waiting for more articles from you.
Thanks! I’ve got plenty in the works.
Thanks. I’ve got a question, though: how to erase just lines with specific infos, i.e. lines that contain infos about app “XY”, not to empty logs completely?
You would need to use sed or awk for this probably. Then again, you just might be able to use egrep. I could probably mess around with it when I have a chance.
Regards,
Drew
Excellent article! my /var/log directory was choking and you article put it on a severe crash diet ;-)
Thanks again..
Excellent article! my /var/log directory was choking and you article put it on a severe crash diet ;-)
Thanks for the comment! I use this command from time to time (usually in a cron job). Keep those log files tame!
Regards,
Drew D.
I’ve been using these commands for a while now and everything was just fine until today. I’m now getting operation not permitted errors such as:
cat /dev/null > /var/log/btmp
-bash: /var/log/btmp: Operation not permitted
Any ideas?
Phil,
What’s changed? Did you upgrade anything? Have you made any changes to the permissions of your files or to the user running the command?
Regards,
Drew
Nope none at all. I normally just login as root to execute the commands…
Phil,
Try running it on a file other than /var/log/btmp. That’s a special file. See if you can either create a new file and run it, or if there is a log file that you don’t need right now, run it on that. Let me know if you get the error on just the /var/log/btmp file or if it is on multiple files.
Regards,
Drew
Seems to be on all of them:
cat /dev/null > /var/log/maillog
-bash: /var/log/maillog: Operation not permitted
cat /dev/null > /var/log/messages
-bash: /var/log/messages: Operation not permitted
cat /dev/null > /var/log/secure
-bash: /var/log/secure: Operation not permitted
Perms are:
-rw——- 1 root root 68408979 Jan 5 12:52 maillog
-rw——- 1 root root 55888419 Jan 5 12:52 messages
-rw——- 1 root root 2208980 Jan 5 12:52 secure
Phil,
I have to head home from work – I work graveyard shift. However, based on your findings, it appears that this is more than my command not working. If the case is that you run cat /dev/null > /var/log/messages, and you get the same error, that is a permissions error with either the user or the files. Check your user and file permissions.
Regards,
Drew
That was my thought as well. I’ve got a friend looking at the system later today but thanks for your help in the mean time…
Phil,
No problem. Were you able to resolve the issue? Also, have you made sure that you weren’t hacked by any chance? Do you have a VM (Virtual Machine) that you can test on to make sure it works on another system that is as close to your production box as possible? Let me know, I can further help you if you need me to.
Regards,
Drew
Right I think I’m getting closer to this. When I check the attributes of the file btmp for example I get:
lsattr btmp
-----a------- btmp
Now on another Linux box there are no attributes set for this file. This response indicates to me that the attributes for the file only allow append right?
running lsattr /var/log shows that all the following logs have the a attribute:
lastlog
maillog
xferlog
boot
messages
cron
secure
wtmp
tty5
faillog
So I ran:
chattr -a btmp
This cleared the attribute and then allowed me to truncate the file. So my question(s) would be:
1) Any idea what would have caused the attributes to change as I don’t recall doing it?
2) can I run chattr -a /var/log to reset the attributes on all the files in the logs directory safely?
Thanks in advance, you have been a massive help :)
Phil,
None of these files really should have been changed. The attributes of /var/log/btmp should be:
# lsattr /var/log/btmp
------------- /var/log/btmp
This also includes all other files in the /var/log directory. To answer your first question, there is not a way for me to figure this out; you could have been hacked, or it could have been an error in a custom script, including a bug. It could have been a legit user that typed in the wrong command, too. Things you should try first would be to check the history:
# history | less
This should show you a list of your whole history of the currently logged on user. You can go through that to see if there is anything that stands out.
To answer question number two, you could enter that command to change that if you would like. Basically none of the files should have any attributes whatsoever, and they should be 600 permissions on files and 755 permissions for directories.
Let me know if you have any questions,
Drew
Thanks Drew. I carried out an extensive review of the box and I’m satisfied that it hadn’t been compromised.
Nothing in the history stands out but I’ll keep an eye on it anyway.
Oh and the commands above I posted worked fine…
Thanks again…
Note: If this is your first time commenting on my site, there will be a delay, as I have to approve your comment.
Ajax AOL/AIM Apache Applications Architecture Career Case Projects CentOS CSS Debian Design File Systems Google Hacks Hardware Humor JavaScript Life Management Movies Networking Open-Standards Personal PHP Programming Registry Samba Security Shell Scripting Software Sys Admin Tech The Notebook Tips UNIX/Linux Virtualization VMWare VPC (MS Virtual PC) Walkthrough Web Apps Windows Work Workaround XHTML XHTML 2.0