Re: Syslog and pg_options (for RPMs)

Can someone address this?

> Bruce Momjian wrote:
> >
> > Seems this was already done in 7.1, right?
> [thread on puts() and fprintf(stderr and printf instead of tprintf or
> replacement truncated]
>
> There are still scads of fprintf(stderr, "some error message from
> postmaster or backend") lying around, in CURRENT as of this morning at
> 1:00AM EDT. Some are things such as the usage message -- others are
> obviously (IMHO) things that need to be sent to the logs. We're not
> replacing the system fprintf , are we? (my assumption is that we are
> NOT). The usage of puts(), OTOH, has been well nigh eradicated.
>
> Try a find -name '*.[hc]' -print -exec grep printf \{\} \; with cwd=src
> to see.... (of course, that also exposes where we are continuing to use
> sprintf instead of snprintf, for whatever reason....)
>
> Comments?
>
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

Bruce Momjian wrote:
>
> Can someone address this?
>
> > Bruce Momjian wrote:
> > >
> > > Seems this was already done in 7.1, right?
> > [thread on puts() and fprintf(stderr and printf instead of tprintf or
> > replacement truncated]
> >
> > There are still scads of fprintf(stderr, "some error message from
> > postmaster or backend") lying around, in CURRENT as of this morning at
> > 1:00AM EDT. Some are things such as the usage message -- others are
> > obviously (IMHO) things that need to be sent to the logs. We're not
> > replacing the system fprintf , are we? (my assumption is that we are
> > NOT). The usage of puts(), OTOH, has been well nigh eradicated.

Where is elog() safe? (Going to Bruce 'comb through the archives' mode
here...)

If someone can educate me in that, I can tackle doing this. Don't know
if I can do so before 7.1 release, but I'll certainly try.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> There are still scads of fprintf(stderr, "some error message from
> postmaster or backend") lying around, in CURRENT as of this morning at
> 1:00AM EDT. Some are things such as the usage message -- others are
> obviously (IMHO) things that need to be sent to the logs. We're not
> replacing the system fprintf , are we? (my assumption is that we are
> NOT). The usage of puts(), OTOH, has been well nigh eradicated.

> Where is elog() safe? (Going to Bruce 'comb through the archives' mode
> here...)

Most places. Not in client communication failures, obviously,
else you'd have instant death by recursion since elog tries to
report to the client (if any) as well as the system log.

That case might (perhaps should be) dealt with by means of some
internal state flags inside elog.

However, it's folly to imagine that we will ever get rid of stderr
output entirely. One glaring example is that on most platforms,
if you have a failure while trying to load a dynamic-link library,
the dynamic linker will emit useful messages (like the names of
unresolved symbols) on stderr. It will never be acceptable to throw
that info away, nor do we have a way to capture it and send it
elsewhere than stderr.

Given these considerations, I'm not all that excited about mounting a
holy war on stdout/stderr messages in the backend code. 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.

regards, tom lane

> However, it's folly to imagine that we will ever get rid of stderr
> output entirely. One glaring example is that on most platforms,
> if you have a failure while trying to load a dynamic-link library,
> the dynamic linker will emit useful messages (like the names of
> unresolved symbols) on stderr. It will never be acceptable to throw
> that info away, nor do we have a way to capture it and send it
> elsewhere than stderr.
>
> Given these considerations, I'm not all that excited about mounting a
> holy war on stdout/stderr messages in the backend code. 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. If someone says we are, the item
is closed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

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

On Thu, 8 Feb 2001, Lamar Owen wrote:

> 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

2>&1 | logger -p facility.level

morannon:~> man logger
LOGGER(1) System Reference Manual
LOGGER(1)

NAME
logger - make entries in the system log

SYNOPSIS
logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [message ...]

DESCRIPTION
Logger provides a shell command interface to the syslog(3) system log
module.

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> AOLserver is one example that successfully redirects dynamic linker
> messages to it's own log.

Oh? How? Are you sure they're not just piping stderr to a program
of their own devising? That's basically what I'm recommending.

> Is syslog not portable enough?

It's got a lot of limitations and problems of its own, on many
platforms... but the fundamental point is that without an external
redirector, we are never going to get everything of interest sent
to syslog.

> 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,

Precisely my point. I think working hard on syslog support inside elog
is misplaced effort.

regards, tom lane

"Dominic J. Eidson" wrote:
> On Thu, 8 Feb 2001, Lamar Owen wrote:
> > A syslogger of stderr would make a nice place to pipe the output :-).
> > 'postmaster .... 2>&1 | output-to-syslog-program -f facility.desired' or

> 2>&1 | logger -p facility.level
[snip]
> Logger provides a shell command interface to the syslog(3) system log
> module.

Good. POSIX required, and part of the base system (basically, guaranteed
to be there on any Linux box). Thanks for the pointer.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > AOLserver is one example that successfully redirects dynamic linker
> > messages to it's own log.

> Oh? How? Are you sure they're not just piping stderr to a program
> of their own devising? That's basically what I'm recommending.

I'm not sure how they're going about it, but, I'll check.

> > 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,

> Precisely my point. I think working hard on syslog support inside elog
> is misplaced effort.

Well, I can think of a few things:
1.) Some messages are more important than others. Syslog levels are
useful to segreggate debug, errors, informational, and critical
messages.
2.) Critical messages might need to go to more than one place, while
debug messages might need to be dropped silently unless further
configuration, etc, is performed.
3.) Some messages need immediate attention -- syslog can go to the
console for level 'crit' messages.

I know that those three points are part of the same point -- but stderr
is but a single stream, relegating all messages to the same priority. I
might want to keep critical messages far longer than debug messages. I
might want to keep FATAL, REALLYFATAL, and even ERROR messages longer
than logs of queries (a likely scenario).

Syslog support in elog(), with proper errorlevel coding, allows the
admin to segregate messages as he sees fit. Using logger(1) means all
messages are the same.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thu, 8 Feb 2001, Dominic J. Eidson wrote:

> On Thu, 8 Feb 2001, Lamar Owen wrote:
>
> > 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
>
> 2>&1 | logger -p facility.level

on linux box I got syslogd eats 45% of cpu.thats why I gave up and
use plain loging to file

>
> morannon:~> man logger
> LOGGER(1) System Reference Manual
> LOGGER(1)
>
> NAME
> logger - make entries in the system log
>
> SYNOPSIS
> logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [message ...]
>
> DESCRIPTION
> Logger provides a shell command interface to the syslog(3) system log
> module.
>
>
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

On Thu, Feb 08, 2001 at 02:43:33PM -0500, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:
> > There are still scads of fprintf(stderr, "some error message from
> > postmaster or backend") lying around, in CURRENT as of this morning at
> > 1:00AM EDT. Some are things such as the usage message -- others are
> > obviously (IMHO) things that need to be sent to the logs. We're not
> > replacing the system fprintf , are we? (my assumption is that we are
> > NOT). The usage of puts(), OTOH, has been well nigh eradicated.
>
> > Where is elog() safe? (Going to Bruce 'comb through the archives' mode
> > here...)
>
> Most places. Not in client communication failures, obviously,
> else you'd have instant death by recursion since elog tries to
> report to the client (if any) as well as the system log.
>
> That case might (perhaps should be) dealt with by means of some
> internal state flags inside elog.
>
> However, it's folly to imagine that we will ever get rid of stderr
> output entirely. One glaring example is that on most platforms,
> if you have a failure while trying to load a dynamic-link library,
> the dynamic linker will emit useful messages (like the names of
> unresolved symbols) on stderr. It will never be acceptable to throw
> that info away, nor do we have a way to capture it and send it
> elsewhere than stderr.
>
> Given these considerations, I'm not all that excited about mounting a
> holy war on stdout/stderr messages in the backend code. 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.

There is a program called "splogger" for that purpose.

Syslog's wire protocol stinks, but partly by design.

Good logging is hard because you don't want to stall real work
waiting to get the messages onto disk or out to the net, but you
also don't want to lose messages. The best you can do under those
circumstances is to buffer log-traffic spikes and hope the averaged
traffic is supportable. Compression can help a lot. Ultimately you
have to decide whether you'd rather stall or would rather lose
messages, if the traffic gets too heavy, and then live with the
result.

Nathan Myers
ncm(at)zembu(dot)com

On Thu, Feb 08, 2001 at 04:00:12PM -0500, Lamar Owen wrote:
> "Dominic J. Eidson" wrote:
> > On Thu, 8 Feb 2001, Lamar Owen wrote:
> > > A syslogger of stderr would make a nice place to pipe the output :-).
> > > 'postmaster .... 2>&1 | output-to-syslog-program -f facility.desired' or
>
> > 2>&1 | logger -p facility.level
> [snip]
> > Logger provides a shell command interface to the syslog(3) system log
> > module.
>
> Good. POSIX required, and part of the base system (basically, guaranteed
> to be there on any Linux box). Thanks for the pointer.

Not so fast... logger just writes its arguments to syslog. I don't
see any indication that it (portably) reads its standard input.
It's meant for use in shellscripts. You could write:

... 2>&1 | while read i; do logger -p local1.warning -t 'PG ' -- "$i"; done

but syslog is pretty high-overhead already without starting up logger
on every message. Maybe stderr messages are infrequent enough that
it doesn't matter.

Nathan Myers
ncm(at)zembu(dot)com

ncm(at)zembu(dot)com (Nathan Myers) writes:
> Not so fast... logger just writes its arguments to syslog. I don't
> see any indication that it (portably) reads its standard input.

FWIW, the HPUX 10.20 man page for logger sez:

A message can be given on the command line, which is logged
immediately, or a file is read and each line is logged. If no file or
message is specified, the contents of the standard input are logged.

and they also claim

STANDARDS CONFORMANCE
logger: XPG4, POSIX.2

The fact that it's POSIX.2 rather than POSIX.1 might worry folks, but
I suspect the majority of systems will have it if they have syslog.

(Curiously, the HP man pages do not say that syslog(3) or syslogd(1m)
conform to *any* standard ... hmm ... is logger more portable than
syslog?)

regards, tom lane

> > Precisely my point. I think working hard on syslog support inside elog
> > is misplaced effort.
>
> Well, I can think of a few things:
> 1.) Some messages are more important than others. Syslog levels are
> useful to segreggate debug, errors, informational, and critical
> messages.
> 2.) Critical messages might need to go to more than one place, while
> debug messages might need to be dropped silently unless further
> configuration, etc, is performed.
> 3.) Some messages need immediate attention -- syslog can go to the
> console for level 'crit' messages.
>
> I know that those three points are part of the same point -- but stderr
> is but a single stream, relegating all messages to the same priority. I
> might want to keep critical messages far longer than debug messages. I
> might want to keep FATAL, REALLYFATAL, and even ERROR messages longer
> than logs of queries (a likely scenario).

Good point.

> Syslog support in elog(), with proper errorlevel coding, allows the
> admin to segregate messages as he sees fit. Using logger(1) means all
> messages are the same.

Totally agreed.

There are still many loggings using just plain fprintf(). They should
be replaced by elog(DEBUG) or elog(NOTICE), IMHO.
--
Tatsuo Ishii

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> There are still many loggings using just plain fprintf(). They should
> be replaced by elog(DEBUG) or elog(NOTICE), IMHO.

I don't disagree with doing that where it's convenient and safe (which
is not everywhere). I'm just pointing out that we need a solution that
covers stderr output as well.

regards, tom lane

On Thu, Feb 08, 2001 at 05:50:55PM -0500, Tom Lane wrote:
> ncm(at)zembu(dot)com (Nathan Myers) writes:
> > Not so fast... logger just writes its arguments to syslog. I don't
> > see any indication that it (portably) reads its standard input.
>
> FWIW, the HPUX 10.20 man page for logger sez:
>
> A message can be given on the command line, which is logged
> immediately, or a file is read and each line is logged. If no
> file or message is specified, the contents of the standard input
> are logged.

Right, I missed where the Linux man page says:

logger [-is] [-f file] [-p pri] [-t tag] [-u socket] [message ...]
...
_message_ Write the message to log; if not specified, and the
-f flag is not provided, standard input is logged.

So now the question is, why did they write splogger? splogger parses
the beginning of each message to assign a severity; if it finds "alert:"
or "warning:" it assigns those, or "info" otherwise. To make splogger
useful you have to know it's listening.

> and they also claim
>
> STANDARDS CONFORMANCE
> logger: XPG4, POSIX.2
>
> The fact that it's POSIX.2 rather than POSIX.1 might worry folks, but
> I suspect the majority of systems will have it if they have syslog.
>
> (Curiously, the HP man pages do not say that syslog(3) or syslogd(1m)
> conform to *any* standard ... hmm ... is logger more portable than
> syslog?)

The Linux page says just:

HISTORY
A syslog function call appeared in BSD 4.2.

Normally if there's a standard they mention it.

Nathan Myers
ncm(at)zembu(dot)com

ncm(at)zembu(dot)com (Nathan Myers) writes:
> So now the question is, why did they write splogger? splogger parses
> the beginning of each message to assign a severity; if it finds "alert:"
> or "warning:" it assigns those, or "info" otherwise. To make splogger
> useful you have to know it's listening.

However, that answers Lamar's complaint about needing a way to control
the syslog level of messages. splogger might be more useful than logger
for our purposes --- even if we have to carry it along with us. What's
its license? A slight tweak of splogger to recognize our ERROR/FATAL/
DEBUG prefixes might be just the thing ...

>> (Curiously, the HP man pages do not say that syslog(3) or syslogd(1m)
>> conform to *any* standard ... hmm ... is logger more portable than
>> syslog?)

> The Linux page says just:
> HISTORY
> A syslog function call appeared in BSD 4.2.
> Normally if there's a standard they mention it.

Yes, the HP man pages also trace it to BSD. I'm surprised syslog
(apparently) hasn't made it into any formal standard.

regards, tom lane

On Thu, 8 Feb 2001, Tom Lane wrote:

> ncm(at)zembu(dot)com (Nathan Myers) writes:
> > The Linux page says just:
> > HISTORY
> > A syslog function call appeared in BSD 4.2.
> > Normally if there's a standard they mention it.
>
> Yes, the HP man pages also trace it to BSD. I'm surprised syslog
> (apparently) hasn't made it into any formal standard.

"man syslog" shows the above, "man logger" however, shows this:

STANDARDS
The logger command is expected to be IEEE Std1003.2 (``POSIX'') compati-
ble.

--
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/

ncm(at)zembu(dot)com (Nathan Myers) writes:

> So now the question is, why did they write splogger?

``They'' didn't write splogger. Dan Bernstein did. It's part of the
qmail distribution. Unfortunately, the license probably precludes
including it with Postgres. Fortunately, it's only 72 lines long, and
would be trivial to recreate.

Ian

On 8 Feb 2001, Ian Lance Taylor wrote:

> ncm(at)zembu(dot)com (Nathan Myers) writes:
>
> > So now the question is, why did they write splogger?
>
> ``They'' didn't write splogger. Dan Bernstein did. It's part of the
> qmail distribution. Unfortunately, the license probably precludes
> including it with Postgres. Fortunately, it's only 72 lines long, and
> would be trivial to recreate.

I missed most of this, but has anyone actually ASKED Dan for permission?
Some of his routines he released into the public domain, some kind of
arrangment may possibly be made. If everyone's afraid to talk to him,
I will.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev(at)michvhf(dot)com http://www.pop4.net
128K ISDN from $22.00/mo - 56K Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================

On Thu, Feb 08, 2001 at 11:36:38PM -0500, Vince Vielhaber wrote:
> On 8 Feb 2001, Ian Lance Taylor wrote:
> >
> > Unfortunately, the license [to splogger] probably precludes
> > including it with Postgres. Fortunately, it's only 72 lines long, and
> > would be trivial to recreate.
>
> I missed most of this, but has anyone actually ASKED Dan for permission?

What's the point? I've attached an independent implementation.
It recognizes tags for all seven levels. It needs no command-line
arguments. Untagged messages end up logged as "LOG_NOTICE".
Use it freely.

Nathan Myers
ncm(at)zembu(dot)com

--------------
/* pglogger: stdin-to-syslog gateway for postgresql.
*
* Copyright 2001 by Nathan Myers <ncm(at)nospam(dot)cantrip(dot)org>
* Permission is granted to make copies for any purpose if
* this copyright notice is retained unchanged.
*/

#include <stdio.h>
#include <stddef.h>
#include <syslog.h>
#include <string.h>

char* levels[] =
{
"", "emerg:", "alert:", "crit:", "err:",
"warning:", "notice:", "info:", "debug:"
};

int lengths[] =
{
0, sizeof("emerg"), sizeof("alert"), sizeof("crit"), sizeof("err"),
sizeof("warning"), sizeof("notice"), sizeof("info"), sizeof("debug")
};

int priorities[] =
{
LOG_NOTICE, LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR,
LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG
};

int main()
{
char buf[301];
int c;
char* pos = buf;
int colon = 0;

#ifndef DEBUG
openlog("postgresql", LOG_CONS, LOG_LOCAL1);
#endif
while ( (c = getchar()) != EOF) {
if (c == '\r') {
continue;
}
if (c == '\n') {
int level = (colon ? sizeof(levels)/sizeof(*levels) : 1);
char* bol;

*pos = 0;
while (--level) {
if (pos - buf >= lengths[level]
&& strncmp(buf, levels[level], lengths[level]) == 0) {
break;
}
}
bol = buf + lengths[level];
if (bol > buf && *bol == ' ') {
++bol;
}
if (pos - bol > 0) {
#ifndef DEBUG
syslog(priorities[level], "%s", bol);
#else
printf("%d/%s\n", priorities[level], bol);
#endif
}
pos = buf;
colon = 0;
continue;
}
if (c == ':') {
colon = 1;
}
if ((size_t)(pos - buf) < sizeof(buf)-1) {
*pos++ = c;
}
}
return 0;
}

Tom Lane wrote:
> However, that answers Lamar's complaint about needing a way to control
> the syslog level of messages. splogger might be more useful than logger
> for our purposes --- even if we have to carry it along with us. What's
> its license? A slight tweak of splogger to recognize our ERROR/FATAL/
> DEBUG prefixes might be just the thing ...

Ok, I can work with that. Last night I dreamed the solution in shell --
what a wicked pipeline..... Might want to change Nathan's pglogger
utility to pg_logger for consistency, though.

A quick and dirty solution that works is better than mucking around with
the core, particularly this close to release.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tom Lane writes:

> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > There are still many loggings using just plain fprintf(). They should
> > be replaced by elog(DEBUG) or elog(NOTICE), IMHO.
>
> I don't disagree with doing that where it's convenient and safe (which
> is not everywhere). I'm just pointing out that we need a solution that
> covers stderr output as well.

Couldn't we redirect stderr to do what we want? dup(), pipe(), fifo, who
knows.

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

Here's the latest version of the pg_logger utility.
The particular questions that come to my mind are:

1. Do the prefixes it watches for match what PG produces?
2. Should it log to LOG_LOCAL1 or to some other LOG_LOCALn?
3. Is the ident string ("postgresql") right?
4. Are the openlog() args right? (E.g. should it ask for LOG_PID too?)
5. What am I failing to ask about?

I'd like to turn it over to whoever can answer those questions.

Nathan Myers
ncm(at)zembu(dot)com

-----------------
/* pg_logger: stdin-to-syslog gateway for postgresql.
*
* Copyright 2001 by Nathan Myers <ncm(at)nospam(dot)cantrip(dot)org>
* This software is distributed free of charge with no warranty of any kind.
* You have permission to make copies for any purpose, provided that (1)
* this copyright notice is retained unchanged, and (2) you agree to
* absolve the author of all responsibility for all consequences arising
* from any use.
*/

#include <stdio.h>
#include <stddef.h>
#include <syslog.h>
#include <string.h>

struct {
char *name;
int size;
int priority;
} tags[] = {
{ "", 0, LOG_NOTICE },
{ "emerg:", sizeof("emerg"), LOG_EMERG },
{ "alert:", sizeof("alert"), LOG_ALERT },
{ "crit:", sizeof("crit"), LOG_CRIT },
{ "err:", sizeof("err"), LOG_ERR },
{ "error:", sizeof("error"), LOG_ERR },
{ "warning:", sizeof("warning"), LOG_WARNING },
{ "notice:", sizeof("notice"), LOG_NOTICE },
{ "info:", sizeof("info"), LOG_INFO },
{ "debug:", sizeof("debug"), LOG_DEBUG }
};

int main()
{
char buf[301];
int c;
char *pos = buf;
const char *colon = 0;

#ifndef DEBUG
openlog("postgresql", LOG_CONS, LOG_LOCAL1);
#endif
while ( (c = getchar()) != EOF) {
if (c == '\r') {
continue;
}
if (c == '\n') {
int level = sizeof(tags)/sizeof(*tags);
char *bol;

if (colon == 0 || (size_t)(colon - buf) > sizeof("warning")) {
level = 1;
}
*pos = 0;
while (--level) {
if (pos - buf >= tags[level].size
&& strncmp(buf, tags[level].name, tags[level].size) == 0) {
break;
}
}
bol = buf + tags[level].size;
if (bol > buf && *bol == ' ') {
++bol;
}
if (pos - bol > 0) {
#ifndef DEBUG
syslog(tags[level].priority, "%s", bol);
#else
printf("%d/%s\n", tags[level].priority, bol);
#endif
}
pos = buf;
colon = (char const *)0;
continue;
}
if (c == ':' && !colon) {
colon = pos;
}
if ((size_t)(pos - buf) < sizeof(buf)-1) {
*pos++ = c;
}
}
return 0;
}

ncm(at)zembu(dot)com (Nathan Myers) writes:
> 4. Are the openlog() args right? (E.g. should it ask for LOG_PID too?)

LOG_PID seems useless, since that would give you the PID of the logger
process, not of the originating backend ...

regards, tom lane