han.holl@informationslogik.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
