Re: Syslog and pg_options (for RPMs)
От | Lamar Owen |
---|---|
Тема | Re: Syslog and pg_options (for RPMs) |
Дата | |
Msg-id | 3A830549.27590831@wgcr.org обсуждение исходный текст |
Ответ на | Re: Syslog and pg_options (for RPMs) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Syslog and pg_options (for RPMs)
("Dominic J. Eidson" <sauron@the-infinite.org>)
Re: Syslog and pg_options (for RPMs) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: