If you squint hard this is on topic:
I have a Registry script that keeps a file open for the life of the child.[1]
The file is opened $|=1.
When a request needs to log something it grabs LOCK_EX, prints, and then
LOCK_UN.
Every night at midnight I archive (rotate) this file. Not running as root,
so I can't shut down Apache while rotating the log.
The archive program opens the same log file, also with $| = 1, grabs a
LOCK_EX, waits two seconds (to let Solaris flush??), and makes a copy of
the log file.
Just for fun, I check the file sizes of the original log file and the
copied file to make sure they are the same. I then truncate the original
log file, print a "new log started" time stamp to the log file, and then
close the file, releasing the lock.
This has been working fine every night for almost two months, but now it
reported that the original log file had grown by a line's worth of characters.
My questions:
? Is the OS buffering the writes to the file so long that even waiting two
seconds after I have a LOCK_EX isn't long enough? Is there a time I can
wait where I know the OS has flushed?
? Is the only safe method to wrap an open/close around every write in the
mod_perl application? That seems like a waste of time.[1] Even if I do
close() after each write, should I still wait some amount of time after
grabbing the LOCK_EX to make a copy?
? Is it better just not to test error conditions ;)
--
[1] Each request creates one or more log messages, so why waste the time
opening the file each request, perhaps multiple times. Also, there are
many places in the script that write directly to the log file, so the
program expects the log file to be open and available for writing at all
times for the life of the request.
BTW - yes, the mod_perl program respects the LOCK_EX. If I run my rotate
log program with a really long wait after getting the LOCK_EX, the mod_perl
aps report that they can't get an exclusive lock on the log file.
And no, there aren't any other programs that write to that log file that
wouldn't respect the lock.
Bill Moseley
mailto:moseley@hank.org
I have a Registry script that keeps a file open for the life of the child.[1]
The file is opened $|=1.
When a request needs to log something it grabs LOCK_EX, prints, and then
LOCK_UN.
Every night at midnight I archive (rotate) this file. Not running as root,
so I can't shut down Apache while rotating the log.
The archive program opens the same log file, also with $| = 1, grabs a
LOCK_EX, waits two seconds (to let Solaris flush??), and makes a copy of
the log file.
Just for fun, I check the file sizes of the original log file and the
copied file to make sure they are the same. I then truncate the original
log file, print a "new log started" time stamp to the log file, and then
close the file, releasing the lock.
This has been working fine every night for almost two months, but now it
reported that the original log file had grown by a line's worth of characters.
My questions:
? Is the OS buffering the writes to the file so long that even waiting two
seconds after I have a LOCK_EX isn't long enough? Is there a time I can
wait where I know the OS has flushed?
? Is the only safe method to wrap an open/close around every write in the
mod_perl application? That seems like a waste of time.[1] Even if I do
close() after each write, should I still wait some amount of time after
grabbing the LOCK_EX to make a copy?
? Is it better just not to test error conditions ;)
--
[1] Each request creates one or more log messages, so why waste the time
opening the file each request, perhaps multiple times. Also, there are
many places in the script that write directly to the log file, so the
program expects the log file to be open and available for writing at all
times for the life of the request.
BTW - yes, the mod_perl program respects the LOCK_EX. If I run my rotate
log program with a really long wait after getting the LOCK_EX, the mod_perl
aps report that they can't get an exclusive lock on the log file.
And no, there aren't any other programs that write to that log file that
wouldn't respect the lock.
Bill Moseley
mailto:moseley@hank.org