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?
Nothing that I know of. That is why this is so frustrating.
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.
Yes, you know what I mean. I used the wrong terminology.
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).
... and further down in the email you will see that one of the things I
tried was to compile the latest version of procmail and it did not
change anything.
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?
It is starting, but not doing anything and is not exiting. If I try to
call procmail, I stop getting any mail of any sort.
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.
Of course I renamed it. I didn't think such a trivial detail needed to
be included.
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.
That is why I am modifying one thing, seeing if it works, and then if it
does not I am modifying something else. It is almost impossible to
diagnose a problem if you change more than one variable at a time.
----- 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.
Yeah, but neither of these two users use their mail enough to realize
that something is screwed up. But I believe it shows that the problem
is not localized to my personal environment.
----- 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.
six binaries.
/usr/local/bin/procmail (v3.13) compiled locally on the mailhost in mid 1999.
/usr/local/bin/procmail.nvs (v3.13) ditto. For sole use of rros44.
/usr/local/bin/procmail (v3.13) compiled on the NFS server for the clients
on the same day with exactly the same code mods.
/usr/local/bin/procmail.nvs (v3.13) ditto.
/usr/procmail/bin/procmail (v3.22) compiled locally on the mailhost last
week.
/usr/procmail/bin/procmail (v3.22) compiled locally on my desktop on the
same day with exactly the same code mods.
The .nvs (Not Very Secure) version I compiled for this one individual
because his very old mailer could not handle proper lockfiles. I
compiled it exactly the same, but with only one lock. His understanding
was that he ran a chance of corrupting his mail file, but went with it
anyway.
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).
Unfortunately that is not it. While yes my home directory is mounted
via NFS, it is mounted from a server running the same OS (Solaris) and
binaries on the NFS server run fine on the NFS clients. My mailspool is
NFS mounted from the mailserver, which is also the same OS, but it has
its own binaries because I am paranoid.
Are you the admin of this host, or just another user?
admin
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.
tail -f /var/log/syslog for several weeks now...
---
Sean B. Straw / Professional Software Engineering
+-----------------------------------------------------------------------+
| Christopher L. Barnard O When I was a boy I was told that |
| cbarnard(_at_)tsg(_dot_)cbot(_dot_)com / \ anybody could become
president. |
| (312) 347-4901 O---O Now I'm beginning to believe it. |
| http://www.cs.uchicago.edu/~cbarnard --Clarence Darrow |
+----------PGP public key available via finger or PGP keyserver---------+
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail