Philips,
Philip Guenther writes on Thu Mar 11 19:41:16 1999:
Lincoln Chang <Lincoln(_dot_)Chang(_at_)sv(_dot_)sc(_dot_)philips(_dot_)com>
writes:
My procmail is: procmail v3.11pre7 1997/04/28
Locking strategies: dotlocking
and my system is:
SunOS systema 5.6 Generic_105181-06 sun4m sparc SUNW,SPARCstation-5
Hmm, that's a pretty old version of the kernel patch for 5.6, which
means you're probably behind on other patches too. You should consider
getting the latest recommended patches from
ftp://sunsolve.sun.com:/pub/patches/
I have already applied a lot of patches including Y2K etc. , the above
'Generic_105181-06' may be misleading because I think it only shows the
time when the kernel is FIRST built with patched I applied at that very
first time.
1. When I open mu Sun Mailtool without closing it, then do the follwing:
% mailx -v myusername < /dev/null
"|IFS=' '&&exec /usr/bin.sun5/procmail -f-||exit 75 # myusername "...
Connecting to prog...
sometimes it just stop there, and there are msg on the console as following:
Mar 10 15:39:42 systema sendmail[887]: PAA00881: SYSERR(root): mailer prog
died with signal 13
Mar 10 15:40:02 systema sendmail[879]: PAA00878: SYSERR(root): mailer prog
died with signal 12
Under solaris 2.6, signal 12 is SIGSYS and signal 13 is SIGPIPE.
SIGSYS means that either a system library is broken or the procmail
binary is corrupt or compiled for the wrong system. Procmail catches
SIGPIPE early on, so that's another sign of a broken binary or library.
I would suggest applying all the recommended patches and making sure
you're using a current and stable compiler (if gcc, at least 2.8.1. If
Sun's cc, make sure you don't have /usr/ucb in your path, as
/usr/ucb/cc is broken). Reconfigure, recompile, reinstall.
I used the Sun WorkShop C compiler. Well, I don't see the above error msg
(ie. signal ...) anymore - may be because last time when I have problem I saw
the procmail is in /usr/bin.sun5 which suprise me (I checked by typing 'which
procmail) and the file size is different than the one I compiled. The procmail
should be under my own ~chang/bin directory, anyway, I copied the one I have
also to the /usr/bin.sun5 for 'just in case'.
One more question: when I type 'procmail -v' it shows that:
Your system mailbox: /var/mail/chang
but my mbox is actually located in my ~chang/mbox (this is just what I want)
because I define my environment MAIL is is /home/chang/mbox. I don't think it
will cause procmail any delay or problem to process the mail, right?
2. The 'procmail: Couldn't unlock "mbox.lock"' msg occurrs MUCH LESS now
after I did:
1) LOCKFILE=$HOME/.lockmail
2) change ":0:" to ":0" in one of the lines in .procmailrc file.
3) use #define NO_fcntl_LOCK
#define NO_lockf_LOCK
in config.h before compiling the new version of v3.11pre7
If you turn off all kernel locking (as required by Sun's broken
MailTool), then the only thing keeping your mailboxes from being
scrambled are the lockfiles. If you tell procmail to use a single
global lockfile, then that'll protect you from multiple simultaneous
procmail's, but not from a procmail process colliding with MailTool.
Such a setup could therefore lose or corrupt messages.
But still occurrs around once per day!
Those would be the times that procmail is colliding with MailTool. My
only suggestion at this point would be to switch from MailTool to
dtmail (the CDE mail GUI) or some other mail user agent.
You are exactly right that the problem is when the procmail process colliding
with MailTool then it still give lockfile problem. Well, I really like
Mailtool more than Netscape tool, so I am going to do 'mailstat $HOME/Mail/from'
once per day to check if any lock file occured, and do a search on the
backup directory. I just have to live with it, or I change to Netscape mail
sometimes in future.
Thanks so much for your input.
Rgds,
Lincoln Chang