Обсуждение: BUG #15363: Logging unexpectedly goes to system event log instead ofstderr

The following bug has been logged on the website:

Bug reference:      15363
Logged by:          Mario Emmenlauer
Email address:      mario@emmenlauer.de
PostgreSQL version: 10.3
Operating system:   Windows 7 x64
Description:

Dear All,

For the past days I've been plagued by a problem where starting postgres.exe
failed. The server postgres.exe would just not start, and stdout and stderr
where completely empty. Even with debugging mode -d 5 there was absolutely
no output. Finally I found the problem (a permission issue about being a
privileged user) with the help of a message in the system event log.

My question is not about the failed startup, but about the logging. I am
confused why the permission problem was logged to Windows system log instead
to stdout/stderr? My postgresql.conf is the default from initdb.exe and
contains only the default #log_destination = 'stderr'. The documentation at
https://www.postgresql.org/docs/current/static/runtime-config-logging.html
says "The default is to log to stderr only".

I'd like to run postgres.exe in my own watchdog, and it works nicely on
Linux and MacOSX. I was relying to see all issues on stdout/stderr. Is it
possible to do the same on Windows, to see absolutely all issues on
stdout/stderr?

Thanks a lot for the very great work, and all the best,

     Mario Emmenlauer

=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> My question is not about the failed startup, but about the logging. I am
> confused why the permission problem was logged to Windows system log instead
> to stdout/stderr? My postgresql.conf is the default from initdb.exe and
> contains only the default #log_destination = 'stderr'. The documentation at
> https://www.postgresql.org/docs/current/static/runtime-config-logging.html
> says "The default is to log to stderr only".

elog.c interprets "write to stderr" like this:

#ifdef WIN32

        /*
         * In a win32 service environment, there is no usable stderr. Capture
         * anything going there and write it to the eventlog instead.
         *
         * If stderr redirection is active, it was OK to write to stderr above
         * because that's really a pipe to the syslogger process.
         */
        else if (pgwin32_is_service())
            write_eventlog(edata->elevel, buf.data, buf.len);
#endif
        else
            write_console(buf.data, buf.len);

I imagine that pgwin32_is_service was yielding true in your situation.
Unfortunately, I don't know if there's much we can do about this;
as I recall, there's no good way for us to discover whether stderr
output goes anywhere useful.

(Hmm, looking at the code, it could also be that pgwin32_is_service
was reporting failure.  I'm not sure whether it's a great idea that
we're effectively assuming we're a service when we can't really
tell.)

            regards, tom lane

Dear Tom and all,

On 05.09.2018 01:23, Tom Lane wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
>> My question is not about the failed startup, but about the logging. I am
>> confused why the permission problem was logged to Windows system log instead
>> to stdout/stderr? My postgresql.conf is the default from initdb.exe and
>> contains only the default #log_destination = 'stderr'. The documentation at
>> https://www.postgresql.org/docs/current/static/runtime-config-logging.html
>> says "The default is to log to stderr only".
> 
> elog.c interprets "write to stderr" like this:
> 
> #ifdef WIN32
> 
>         /*
>          * In a win32 service environment, there is no usable stderr. Capture
>          * anything going there and write it to the eventlog instead.
>          *
>          * If stderr redirection is active, it was OK to write to stderr above
>          * because that's really a pipe to the syslogger process.
>          */
>         else if (pgwin32_is_service())
>             write_eventlog(edata->elevel, buf.data, buf.len);
> #endif
>         else
>             write_console(buf.data, buf.len);
> 
> I imagine that pgwin32_is_service was yielding true in your situation.
> Unfortunately, I don't know if there's much we can do about this;
> as I recall, there's no good way for us to discover whether stderr
> output goes anywhere useful.
> 
> (Hmm, looking at the code, it could also be that pgwin32_is_service
> was reporting failure.  I'm not sure whether it's a great idea that
> we're effectively assuming we're a service when we can't really
> tell.)

Aaah! Yes things make sense now, looking at elog.c! Thanks.

But just to ask, is it so fatal for a service to print to console?
I recall from Windows XP that there was a buffer of several hundred
KB that could be filled before it eventually killed the application.
In case of my specific problem, it would have been really helpful if
either:
 - a message on console would have pointed to the log redirection, or
 - the fatal error (before program termination) would have been printed
   on console, possibly in addition to the event log.

Would any of this make any sense to you?

All the best and thanks again,

    Mario Emmenlauer


--
BioDataAnalysis GmbH, Mario Emmenlauer      Tel. Buero: +49-89-74677203
Balanstr. 43                   mailto: memmenlauer * biodataanalysis.de
D-81669 München                          http://www.biodataanalysis.de/