In message <000801bd74bc$4537cb40$ba032599(a)Ritch.earthlink.net>, "David B. R
itch" writes:
>We have had numerous problems dealing with SunOS and Solaris mailtool file
>locking after moving our mail spool off our Solaris server. Initially, we
>moved the spool to a Network Appliance and used a Digital Unix system as the
>mail server. In an attempt to solve the locking problem, we moved the spool
>to a local filesystem on the Digital Unix box, but we still had problems.
>When we switched from binmail to procmail as our mail delivery agent, most
>of the problems were resolved.
Odd, our problems seem to stem from mailtool / procmail
interaction. It doesn't look like mailtool is freeing locks, so
procmail can't write to the spool. But this didn't occur (at least
procmail didn't complain about) before we moved the spool from the
4.1.3_U1 mail server to the NetApp.
>In all of the mess, we learned a couple of things to look for: Is there a
>cron job on the Sun that clears locks older than a few minutes? If so, you
No, and that shouldn't be necessary. procmail is smart enough to
timeout stale locks.
>might need a similar workaround on the NetApp filesystem. Are your users
>exiting OpenWindows without clicking "Done" (to save changes)? It is a bug
>to leave the file locked, but I believe that some versions of mailtool do
>this. Do your users find that their mailtools get confused? We found that
>to be a symptom of locking problems. Do your users have large inboxes? Our
>mailtool and dtmail users have a tendency to keep lots of old mail in their
>inboxes, and the resultantly large mail files take longer to update. This
>increases the likelihood of two processes needing to lock the file at the
>same time.
These problems occur while users are running mailtool. We have the
latest pathes regarding filelocking installed for SunOS 4.1.3_U1
and Solaris 2.5, 2.5.1, & 2.6. When they exit mailtool, everything
is fine.
>You might also want to rebuild procmail. When you build it, one thing it
>does is to test locking in your mail spool directory, so that it can
>determine what locking mechanisms work reliably. It may be that it needs to
>run those tests again on your new filesystem.
Yep. Already tried it.
>On the other hand, you might want to switch to pop3 or imap4 (if possible)
>to get mail to your users' workstations. These seem to be more robust
>protocols than nfs with locking.
If I could just get them to use something other than mailtool, I
wouldn't have a problem. pine, elm, nmh, qpopper, and Netscape
(movemail) all seem to be ok. mailtool seemed to be fine when
mounting from the 4.1.3_U1 spool, now it's brain-dead.
>Good luck. Dealing with mail problems can be unpleasant.
Tell me about it... Thanks for your help.
jason
