Riddle me on this one
Christopher Browne
cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Sun Jan 22 03:12:46 UTC 2012
On Sat, Jan 21, 2012 at 5:48 PM, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:
Decidedly a fuller explanation than I gave...
> The logging system has ways for rolling over logs. I don't remember
> them, but they are what you want to use if you space is eaten by a log
> file.
Actually, I would characterize it in something of an opposite way...
Log rotators switch over the files so that the log data gets 'sucked
out' into a secondary file, and then truncates it from the "main"
file.
If you have actually run out of disk space, log rotation won't
actually help, as the rotation process temporarily needs that there be
enough free space to capture the data that is being rotated out of the
"main" log file.
But assuming you're not actually out of space, this process "sucks"
the early portions of the log file out into another file, whilst not
interrupting the process being logged which wants to keep writing out
information about its activities at the end of the log file.
By doing that regularly, and dropping the eldest log files, this
restricts the space being chewed up by log files.
Unfortunately, if you get to the point where:
a) You're actually out of space, there's no place for the rotation
process to do its work.
There is good analogy here to doing backups. You need to set up log
rotation *before* you need it, just as you need to set up backups
*before* you need them.
If you don't have a backup, and have a problem that requires one,
you're Outta Luck. Likewise, if you haven't set up log rotation,
"when you run out of disk space" is too late a point for rotation to
really help.
It's not as bad as lacking backups; it ought to be reasonable to
delete a log file or three, or "echo '' > something.log", to empty
something out.
b) If the only remaining file descriptor is held by some live process,
and the file is otherwise unlinked, log rotation will also do you no
good, as it has no way of getting at the file to suck data out of it.
Frankly, at that moment, you pretty much need to "kick" the process
holding the file descriptor, to make it give it up. Whether that's
something like "kill -HUP" or "kill -9" depends on what signals the
process is prepared to recognize.
For anyone interested in more details take a look at the source code
to logrotate:
http://logrotate.sourcearchive.com/downloads/3.7.1/
See the function copyTruncate() in logrotate.c
--
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
More information about the Legacy
mailing list