At 11:38 2003-09-15 -0500, Christopher L. Barnard wrote:
I have a pretty basic procmail question. procmail stopped working about
two weeks ago and I cannot get it to start up again. I have run out of
ideas about what to try, so I am hopeful that someone on this list can help.
Well, what was changed two weeks ago?
This is Sun, the mailhost is Solaris 7. It is running the stock sendmail as
shipped by Sun. Procmail is not integrated into Sendmail.
You mean, "procmail is not the LDA". There really isn't any "integration"
with the MTA, even when procmail is the LDA.
This has been working for years -- /opt/local/bin/procmail is version 3.13
but it works fine.
Uh, well you aught to consider upgrading it in any event. If your procmail
is that old, I can't help but wonder how old your sendmail might be (esp.
if, as you say, it's the stock one shipped by Sun).
But what procmail appears to be doing now is consantly fighting over the lock
on my mailspool file. From my procmail log:
[...]
procmail: [3178] Thu Sep 11 09:34:58 2003
procmail: Locking "/var/mail/cbar44.lock"
Uh, if you have a procmail log of your own, then I'd have to say that
procmail IS starting, now isn't it?
I deleted the .forward so that I could continue to get mail.
Normally, people simply rename (mv) the file. That way, it retains the
same content and permissions, and when you go to recreate it later on, you
don't boff something in the process of rekeying it, say with a typo or bad
perms.
LOGFILE=$PMDIR/log
INCLUDERC=$PMDIR/rc.maillists
As with the .forward, a better way to disable code which is INCLUDERC'd, is
to simply comment out the INCLUDERC line. No need to blitz the content of
the included file.
You're not doing yourself any favours by deleting or overwriting file
contents in pursuit of the diagnostic process - you very well may end up
fixing the original problem, and then when you go to restore your
(previously working) config, you'll introduce some other problem.
----- The following addresses had permanent fatal errors -----
"|/usr/local/bin/procmail.nvs -f- #rros44"
(reason: 1)
(expanded from: rros44)
"|/usr/local/bin/procmail #jedd44"
(reason: 1)
(expanded from: jedd44)
Ok, looks like you've just established that the problem you're having is
not limited to just your account, since there's another boffed user there.
----- Transcript of session follows -----
sh: /usr/local/bin/procmail.nvs: not found
.nvs ? You're dealing with more than one binary between yourself and the
other user referred to in that bounce.
<http://rhols66.adsl.netsonic.fi/era/mail/procmail-debug.html>
Suggests that "unknown mailer error 1" may be returned if the procmail was
compiled for the wrong architecture. IOW, your mail may be getting handled
on a machine which is mounting your home directory via NFS, and the
binaries being used are incompatible (or wholly unavailable).
Linked from the above page is:
<http://www.xray.mpe.mpg.de/mailing-lists/procmail/1997-09/msg00526.html>
Are you the admin of this host, or just another user?
You *REALLY* should examine /var/log/maillog (or wherever you've got the
MTA dumping log info), and check what the MTA acutually has to say about
the problem.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail