Bruce Momjian wrote:
> > Given these considerations, I'm not all that excited about mounting a
> > holy war on stdout/stderr messages in the backend code.
Holy War? Not quite -- just a desire for consistency. Not terribly
important -- just cleaning out my over-stuffed inbox.
> > It'd be more
> > profitable to leave the code as-is and figure out a way to cause
> > stdout/stderr output to be logged in a more admin-friendly manner.
> > I like the idea of piping the output to a log-rotation program.
> I am not out to eliminate it. I just want to be sure that we are using
> elog()/fprintf() in the proper places.
I _would_ like the output that is useful logging to be directable, as is
the case with elog(). It is nice to be able to runtime-configure
logging destinations -- syslog, stderr, both. If useful logging output
is going to stderr when I'm looking in a syslog-managed file elsewhere
(like on another hardened log bastion host running syslog with remote
reception), it might as well not even go to stderr at all. And as far
as dynamic linker output is concerned, that typically gets sent to
syslog as well, through other channels, at least in my experience.
AOLserver is one example that successfully redirects dynamic linker
messages to it's own log.
Is syslog not portable enough? Log rotation of syslog-generated
logfiles is stock fodder on most Unixoid systems. And PostgreSQL 7.1's
support of syslog is much better than 7.0's.
A syslogger of stderr would make a nice place to pipe the output :-).
'postmaster .... 2>&1 | output-to-syslog-program -f facility.desired' or
some such. But that obviates the need to support syslog _at_all_ in the
backend, unless you want the stuff on stderr to go to a different
facility from the rest.
But the original complaint was that log messages were getting lost
because they were going to stderr or stdout when the admin had
specifically configured for everything to go to syslog.
When working in the total OS environment, and you already have generic
log analysis tools set up to work with the OS vendor's logrotate, etc,
it pays to not reinvent the wheel but use the conventions and tools
already provided in the OS. Syslog is a standard way to do this.
Why even have syslog support otherwise? (Extremist? Maybe.)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
