RPN01 wrote:
It really depends on if the logging program keeps the file open on a file
handle, or opens and closes the log file as it has things to add. If you mv
That would be very bad for performance.
A programmer can write an application to allow a file's writes to be
cached or require writes to be written immediately (according to some
definitions of immediately), and syslogd allows the user to make that
choice in the way they specify log files.
the log within the same filesystem, many times the logging program will just
continue to log to the original file in its new location.
For the result of the mv to be effective, the application must reopen
its log file. I don't know of one that does so without being told.
If a log file is moved across filesystems, the application will keep
writing to the old, deleted, file until it's closed (and really
deleted). You do not want to do that.
Basically, you'll get varying results doing things like this, so everyone's
mileage will vary.
No.
Everyone's mileage will be the same for the same actions with the same
program. Read its documentation to see how to cycle logs correctly.
As I said before, logrotate can handle most logfiles.
--
Robert P. Nix Mayo Foundation .~.
RO-OE-5-55 200 First Street SW /V\
507-284-0844 Rochester, MN 55905 /( )\
----- ^^-^^
"In theory, theory and practice are the same, but
in practice, theory and practice are different."
On 11/6/08 7:24 PM, "John Summerfield" <[EMAIL PROTECTED]>
wrote:
John McKown wrote:
I was just having a discussion here. We had a Tomcat log file exhaust all
the space on a filesystem. An Oracle person said that they often
"truncate" Oracle logs, while Oracle is still running by doing something
like:
cp oracle.log /some/other/filesystem
That copies the oracle log, it does not change it.
tail -20 /some/other/filesystem/oracle.log oracle.log
That prints the last 20 records of each.
Possibly, someone meant
tail -20 /some/other/filesystem/oracle.log >oracle.log
I wouldn't think that would do anything but corrupt the log, but I don't
have a log file I care to try it on.
At the very least, there's a race condition, and anything logged between
the completion of the mv command and the tail command working (if indeed
it does, and that I doubt) is lost. And you know what Murphy said!
He indicated that this causes the file to shrink in size and Oracle then
continues logging after the 20 records copied.
I'm thinking that this is dependant on Oracle, or whatever application,
using the O_APPEND option on the fopen() call. If the program doesn't use
O_APPEND, then the space is not released and the program continues writing
at the end and the file continues to increase in size.
Am I understanding this correctly?
What might work, if tomcat is written for it to work, is something like
this:
mv tomcat.log tomcat.log.0
service tomcat reload
There's no file locking, so the mv renames the file while it's being
written. I would not move it to another filesystem at this point, harm
will ensue.
Ordinarily, the service command runs the named script from /etc/init.d
and the reload argument sends a SIGHUP signal to the application, and by
convention, the application rereads its configuration and closes/opens
its logs. Whether this works with tomcat is something you need to
explore in its documentation.
You have an application, logrotate, that can (and should) do this. It is
configurable as to how many logs are kept and whether they are
compressed. From its man page:
LOGROTATE(8) System Administrator's Manual
LOGROTATE(8)
NAME
logrotate - rotates, compresses, and mails system logs
SYNOPSIS
logrotate [-dv] [-f|--force] [-s|--state file] config_file+
DESCRIPTION
logrotate is designed to ease administration of systems
that generate large numbers of log files. It allows automatic
rotation, compression, removal, and mailing of log files. Each
log file may be handled daily, weekly, monthly, or when it
grows too large.
--
Q: What do theoretical physicists drink beer from?
A: Ein Stein.
Maranatha!
John McKown
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
