>> What do you think of the following as a fix?
>
>I dislike going through write_stderr because it requires an extra,
>useless gettext() call,
It does? Isn't buf.data already "gettextified"? write_stderr just calls
vfprintf. Or is this an example of me not knowing how gettext works?
> and because in the Windows case it imposes
> an arbitrary length limit that is certain to be exceeded.
> The length
>limit is probably OK for the existing limited usages of write_stderr,
>but you can't assume that every log message the system ever prints
>is going to be under 2K.
We're not assuming that!
If the system is configured to log to eventlog, this code is never
called.
If the system is configured to log to a file (redirect_stderr), this
code is never called.
It is *only* called when:
- System has not read it's full configuration yet (which is the case we
are trying to address)
- System is configured for logging to stderr *without* capturing it to a
file *and* running as a service. I'd argue this is a configuration
error.
>The proposed test on Redirect_stderr looks pretty fishy too; for one
>thing it will almost certainly not be the right thing inside the stderr
>logger subprocess itself.
Could you explain further what the issue is there?
There is special code in the send_message_to_server_log function to make
sure it's written directly to the file.
//Magnus
