Riddle me on this one

[Christopher Browne]

On Sat, Jan 21, 2012 at 12:18 PM, William Muriithi
<william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> Morning
>
> I have a system that is maxing up the disk space and was trying to
> find a logs to purge.  The odd thing is, the root of the log directory
> reports 3.6G, but all the logs file living on that directory do not
> even come close to the sum of all the logs file size added up.
>
> du -h /var/log
> 4.0K    /var/log/unattended-upgrades
> 4.0K    /var/log/apparmor
> 4.0K    /var/log/landscape
> 4.0K    /var/log/dist-upgrade
> 56K     /var/log/apt
> 40K     /var/log/ConsoleKit
> 824K    /var/log/exim4
> 4.0K    /var/log/news
> 4.0K    /var/log/jetty
> 12K     /var/log/fsck
> 3.6G    /var/log
>
> Why would that happen?  How would I fix it?  Someone seem this before?
>  Really odd, or I am missing something fundamental

I have seen this phenomenon when a file has been removed while a
process is still writing to it.

>From the directory structure perspective, that file is no longer
accessible, but it's still being written to.

That could happen if you have:
a) A process writing to the log file, then
b) Another process (say, a log rotator) renames the file, and then
unlinks it, while a) still has the file open.

A reboot would (ahem!) resolve this silently; close out the process
that's writing to the file, and the unlinking completes.

That's overkill - it really suffices to kill the single process that's
writing to the file.

I expect you could use fuser to find the process, but leave that as
exercise to the reader :-)


-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists