I had some unexplained sendmail failures, and I'm hoping that someone can
shed some light on the following excerpt from my log file:
----------
From useraddress Fri Jul 18 14:12:20 1997
Subject: original subject
Folder: /usr/sbin/sendmail -oem -odi -oi -flistname(_at_)domain 1793
procmail: Timeout, terminating "/usr/sbin/sendmail"
procmail: Program failure (-256) of "/usr/sbin/sendmail"
procmail: Kernel-lock failed
procmail: Kernel-unlock failed
--------
elsewhere I get:
procmail: Skipped "/home/listproc/temp/DAEMON.lock"
Note that logging wasn't verbose (famous last words - I hadn't had problems
up till now, so figured I could conserve disk space). The problem has come
and gone, so it isn't as if enabling verbose now will allow me to catch
more info on this specific incident.
Several questions:
1. Why would sendmail timeout? Now, it seems that the messages are
successfully queued (they have since appeared in remote mailboxes,
with the exception of one message that appeared in the system
messagelog as being deferred), but these nastygrams are really
concerning.
2. Kernel-lock failed - why, where?
3. If the kernel-lock failed, doesn't it stand to reason that an attempt
to unlock will ALSO fail? Why is the unlock even attempted when the
lock fails (or is this "just in case" the lock failed because of an
existing lock - which I forsee possible problems with too)?
4. The DAEMON.lock is an oddity unrelated to the current sendmail
failure - it doesn't appear to be processed in sync with the
individual messages (If I get a slew of messages, I may see several
procmail reports with header info, THEN have a stream of five or six
(or whatever number of messages) of these DAEMON.locks. The daemon
lock is a gzip for mailer daemon messages (so they don't forward).
I'd like to get this stuff to show up in sync - how can I do that?
I got a whole slew of these failures (no changes to the procmail config),
and I'm really perplexed. Some messages in the group went through just fine.
Would this possibly be caused by a dropped network connection (the local
telco - PacBell - seems to screw up the T1 trunk between my server and the
rest of the universe with entirely too much frequency) - but I've never had
this problem before.
What exactly is the 1793 at the end of the folder line? I'd initially
thought it might have been a PID, but it doesn't match up to anything in my
syslog or messages file. Apparently this is a message size? How can I go
about tracking down the actual process results that were running at the
time? The timestamp on the from in the log allows me to match it against
the logging of the _incoming_ message, but little else.
Also, in the message log, I see only one message that timed out while
communicating with a remote SMTP server (and was deferred) -- all other
sendmail transactions there show messages as accepted for delivery. Yet, I
got these items in the log for about 18 separate messages.
versions: sendmail 8.8.5, procmail 3.10
(yea, I've got to take my compiled 3.11pre7 and put it into operation -
does anyone know of any reason I _shouldn't_ do it with this ver?).
Any assistance would be greatly appreciated.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395