William A. Rowe, Jr. wrote:
Mladen Turk wrote:
Hi,
Currently rotatelogs (at least on windows) holds the initial
log file by parent process (well it tries to rotate if something
is written from parent which is impossible for access logs).
I plan to use the apr_wait_for_io_or_timeout before calling
the apr_file_read(f_stdin, ...). This would give a chance
to parent to rotate his log as well and release the initial
log file descriptor.
Would that make any problems if executed in the parent?
Since apr_wait_for_io_or_timeout is posix only API, some
#ifdef _WIN32 would be required in rotatelogs
Wouldn't it be better if we simply implement the mechanism to share
the same handle between the parent and child?
Since the parent does not receive any access log hits how
would that prevent it from holding that handle forever?
I'd leave rotatelogs alone, please. Its design is not flawed. But
I think Jim was working on something which would release the file
just as soon as its time is up, and that is useful across all of
the architectures, not windows specific.
Using 1 second wait before reading from the stdin would give
the required rotate resolution. In case of APR_TIMEUP it's
just a continue in the for (;;) loop giving change to rotate
logic to handle the files.
For Windows we can use apr_file_pipe_timeout_set(f_stdin, ...
Dunno if there's a bug in APR/win32, but you can actually always
set a timeout on a apr_file_t unlike on unix where this
is possible only if apr_file_t is a pipe.
And I would certainly like to hear from Jim what he proposes
for rotatelogs solution for holding the file handles in parent.
Regards
--
^(TM)
