BUG #15363: Logging unexpectedly goes to system event log instead of stderr
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/