Thread: Syslog and pg_options (for RPMs)
Well, I got pg_options and syslog (and ELOG timestamping) figured out -- however, there is a quirk: With syslog set to 2 (supposedly suppressing ANY stderr/stdout, I still get some output (I know that the documentation mentions this) )-- the output I am getting is "reset_client_encoding().. reset_client_encoding() done" immediately after a InitPostgres log line. Incidentally, the two reset_client_encoding lines are not timestamped, while the InitPostgres line IS. To get syslog functionality working (at least under RedHat Linux 6.1/Intel), do the following: Either edit src/include/config.h.in before configure, or edit src/include/config.h after configure but before make (for RPM-building, I patch config.h.in before running configure) -- uncomment both ELOG_TIMESTAMPS and USE_SYSLOG. In $PGDATA/pg_options, make verbose=1 or 2, and syslog >0 -- read the pg_options page in the admin docs for more stuff you can put in pg_options. To get information into the syslog, in /etc/syslog.conf place a line: local0.* /var/log/postgresql and /var/log/postgresql will get ALL those messages. NICE. Log rotation under RedHat is a simple config file in /etc/logrotate.d...... These changes (including the syslog.conf one) will be in the next RPM set to be released. Massimo, what syslog levels are you using (I've perused src/backend/misc/trace.c, but, unfortunately, my knowledge of syslog code is weak)? Man, those regression tests really issue the queries (normally, my system will do the non-parallel regression in about 2:15, but with syslog and query=4, it takes 3:14). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Well, I got pg_options and syslog (and ELOG timestamping) figured out --
> however, there is a quirk:
>
> With syslog set to 2 (supposedly suppressing ANY stderr/stdout, I still get
> some output (I know that the documentation mentions this) )-- the output I am
> getting is "reset_client_encoding()..
> reset_client_encoding() done" immediately after a InitPostgres
> log line. Incidentally, the two reset_client_encoding lines are not
> timestamped, while the InitPostgres line IS.
It seems that there is some code which doesn't use elog() or TPRINTF() but
outputs directly to stderr instead. For example in postgres.c:
#ifdef MULTIBYTE/* set default client encoding */if (Verbose)
puts("\treset_client_encoding()..");reset_client_encoding();if(Verbose) puts("\treset_client_encoding() done.");
#endif
In my opinion this is wrong. It should be:
TPRINTF(TRACE_VERBOSE, "reset_client_encoding().."");
or better:
TPRINTF(TRACE_MULTYBYTE, "reset_client_encoding().."");
A quick grep shows that the following files contain puts()
src/backend/access/common/printtup.c: src/backend/bootstrap/bootparse.c: src/backend/bootstrap/bootstrap.c:
src/backend/executor/execAmi.c: src/backend/libpq/be-dumpdata.c: src/backend/nodes/copyfuncs.c:
src/backend/parser/parse_expr.c: src/backend/tcop/postgres.c: src/backend/utils/adt/dt.c:
src/backend/utils/adt/ruleutils.c: src/backend/utils/init/postinit.c: src/backend/utils/misc/database.c:
src/backend/utils/sort/lselect.c: src/bin/psql/psql.c: src/interfaces/libpgtcl/pgtclId.c:
and many other files contain printf().
> To get syslog functionality working (at least under RedHat Linux 6.1/Intel), do
> the following:
>
> Either edit src/include/config.h.in before configure, or edit
> src/include/config.h after configure but before make (for RPM-building, I patch
> config.h.in before running configure) -- uncomment both ELOG_TIMESTAMPS and
> USE_SYSLOG.
You can also add the following line into Makefile.custom:
CUSTOM_COPT += -DUSE_SYSLOG -DELOG_TIMESTAMPS
> In $PGDATA/pg_options, make verbose=1 or 2, and syslog >0 -- read the
> pg_options page in the admin docs for more stuff you can put in pg_options.
>
> To get information into the syslog, in /etc/syslog.conf place a line:
> local0.* /var/log/postgresql
> and /var/log/postgresql will get ALL those messages. NICE. Log rotation under
> RedHat is a simple config file in /etc/logrotate.d......
>
> These changes (including the syslog.conf one) will be in the next RPM
> set to be released.
>
> Massimo, what syslog levels are you using (I've perused
> src/backend/misc/trace.c, but, unfortunately, my knowledge of syslog code is
> weak)?
LOG_DEBUG, unless you enable the "all" trace flag, in which case LOG_INFO
is used.
> Man, those regression tests really issue the queries (normally, my system will
> do the non-parallel regression in about 2:15, but with syslog and query=4, it
> takes 3:14).
>
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>
> ************
>
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-0461534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+
Can someone comment on 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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian wrote: > > Can someone comment on this? You can tell we're getting close to beta when Bruce combs through the archives.... :-) The situation has not changed much. There is still code printing to stderr and stdout that quite possibly should be using the standard logging system that can timestamp and syslog. One of my favorites in the heap am statistics printout. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Bruce Momjian wrote: > > > > Can someone comment on this? > > You can tell we're getting close to beta when Bruce combs through the > archives.... :-) Man, we have been around here too long. :-) -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
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.owen@wgcr.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@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
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.owen@wgcr.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.owen@wgcr.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@sai.msu.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.owen@wgcr.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@zembu.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@zembu.com
ncm@zembu.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@sra.co.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@zembu.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 notspecified, 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@zembu.com
ncm@zembu.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@zembu.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@zembu.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@zembu.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@michvhf.com http://www.pop4.net128K ISDN from $22.00/mo - 56K Dialup from $16.00/moat 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@zembu.com
--------------
/* pglogger: stdin-to-syslog gateway for postgresql.** Copyright 2001 by Nathan Myers <ncm@nospam.cantrip.org>*
Permissionis 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@sra.co.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@gmx.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@zembu.com
-----------------
/* pg_logger: stdin-to-syslog gateway for postgresql.** Copyright 2001 by Nathan Myers <ncm@nospam.cantrip.org>* This
softwareis 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
allresponsibility 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@zembu.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