Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Postgres logs to syslog LOCAL0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: han(dot)holl(at)informationslogik(dot)nl
Cc: pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: [GENERAL] Postgres logs to syslog LOCAL0
Date: 2005-10-17 17:19:27
Message-ID: 9868.1129569567@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-general
han(dot)holl(at)informationslogik(dot)nl writes:
> On Monday 17 October 2005 15:57, you wrote:
>> What platform are you on, exactly?  I'm hoping it's something we can
>> look at the source of openlog for ...
>> 
> You sure can: Redhat Linux 9, glibc-2.3.2-27.9.7

Hmm, the closest I can find in Red Hat's archives is glibc-2.3.2-27.9.6 ??
Should be close enough for this though.

Digging around in that source tree, I see that:

* openlog stores its first argument in a static variable LogTag,
  if the first argument isn't NULL.

* closelog resets LogTag to NULL, but it doesn't touch the other saved
  values.

* syslog does this:

	    if (LogTag == NULL)
	      LogTag = __progname;
	    if (LogTag != NULL)
	      fputs_unlocked (LogTag, f);

where __progname is an internal glibc variable initialized by crt0.
I didn't bother to track down the details of __progname, but it seems
highly likely that it points to the original value of argv[0].

So now we can explain all the symptoms:

	* elog.c does an initial openlog() call, which it relies on
	  being good henceforth.

	* your routine overwrites the parameters by doing another openlog().

	* then you do closelog().  At this point LogTag is reset to NULL
	  but the option and facility settings remain as you set them.

	* the next syslog() call sets LogTag to point into the original
	  argv space, then does an implicit openlog().

If you look at ps_status.c, it's not too surprising that LogTag would
end up pointing at some part of our current process status string.
Therefore we now understand the bizarre appearance of the status string
where "postgres" should be, plus the disappearance of the pid (LOG_PID
got turned off), plus the selection of LOG_LOCAL0.

In short, you've got to change that preloaded library.  It has no
business calling either openlog or closelog.  The only way the backend
could defend itself against this is to call openlog again for every
syslog call, which we are certainly not going to do because of
performance considerations.

The changes I made in elog.c over the weekend seem not to be related
to your problem at all.  Still, I think they are good robustness
improvements and I don't plan to revert them.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Andri gunawanDate: 2005-10-18 06:18:24
Subject: BUG #1973: Error on installation after uninstall PostgreSQL
Previous:From: Eduardo SoaresDate: 2005-10-17 17:00:21
Subject: BUG #1972: index error with space character

pgsql-general by date

Next:From: Jim C. NasbyDate: 2005-10-17 17:25:18
Subject: Re: unsigned types
Previous:From: Chris BrowneDate: 2005-10-17 17:14:57
Subject: Re: [pgsql-advocacy] Oracle buys Innobase

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group