Well, as is frequently the case, the mere act of posting something
started some different brain gears turning, so I decided to do some
more poking around. In my previous post, I said ...
>> But on the other hand, if I do something like
>>
>> logger -p mail.somepriority "some test message"
>>
>> ... the message *always* ends up in mail.log on loghost, even in
>> cases where I do this on a DUnix system. So it seems that this
>> syslog problem occurs only with messages emitted by sendmail and
>> only when sendmail is running under Digital UNIX.
As it turns out, the test messages I was using were short. Figuring
that maybe something about the *length* of the messages just may be
relevant, I tried using "logger" with a copy of a message which was
actually logged by sendmail. Bingo! Here's what I've found:
-- When using "logger" to log a message longer than a certain length
(sorry, I haven't yet quantified what that length is), the message is
split into multiple messages. If possible, the split is made between
two consecutive argv elements. Otherwise, it just makes the split at
some other point.
In other words, if I do
x="Some incredibly long message including whitespace"
then
logger -p mail.debug $x
and
logger -p mail.debug "$x"
get split differently, with the first making the split at a whitespace,
and the latter making it elsewhere.
-- When a long message is logged this way, sometimes the first chunk
gets logged to the wrong file on loghost; the second chunk seems to be
logged to the correct file every time.
-- This chopping of the message seems to be getting done by "logger"
itself, not by anything in the deeper-down innards of the syslogging
stuff, since messages logged by sendmail via syslog(3) appear as one
single long message (albeit to the wrong logfile most of the time).
However, something really peculiar is going in with long messages in
both cases.
So my suspicion (though, short of grabbing the syslog packets that are
being sent from the DUnix system to the syslogd on loghost, it's hard
to verify my hypothesis) is that the problem is related to whatever it
is that DUnix is doing when a message exceeds some threshold. It does
appear that loghost's syslogd is doing what it's supposed to, but that
it's getting incorrect information from the DUnix system.
Does anyone know of reports of problems of this sort? Is there a patch
out that fixes it?
In any case, I'll keep bashing away at it until I can categorize things
a bit more accurately (e.g. what message length makes things break) and
will report back.
Mark Bartelt 416/978-5619
Canadian Institute for mark_at_cita.utoronto.ca
Theoretical Astrophysics
http://www.cita.utoronto.ca/~mark
"Clothes not busy being worn are busy drying." -- Dylan, on laundry day
[ singing "It's all right, ma (I'm only bleaching)" ]
Received on Thu Feb 12 1998 - 16:34:50 NZDT