In message 000801bd74bc$4537cb40$ba032599@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
I am not a "mail" or "procmail" expert. But this is what we did to get our sendmail on HP to lock/unlock mail files properly on FAServer. Pay special attention to mail directory permissions: HP# ls -ld /var/mail lrwxrwxrwx 1 root sys 18 Feb 2 11:00 /var/mail -> /net/roti/home/mail HP# cd /var/mail (File system now is a F540; 'roti' is the F540) HP# cd .. HP# ls -ld mail drwxrwxrwt 3 root mail 16384 May 1 13:01 mail ^ HP# cd mail HP# ls -ld thomas -rw-rw---- 1 thomas mail 1706670 May 1 12:55 thomas
Philip Thomas Motorola - ATL, M/S M350 2200 W. Broadway M350 Mesa, AZ 85202 rxjs80@email.sps.mot.com (602) 655-3678 (602) 655-2285 (fax)
-- Begin original message --
From: "Jason D. Kelleher" kelleher@susq.com Date: Fri, 01 May 1998 15:08:49 -0400 Subject: Re: file locking problem To: "David B. Ritch" dbritch@earthlink.net Cc: toasters@mathworks.com
In message 000801bd74bc$4537cb40$ba032599@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
-- End original message --
---philip thomas
From: Philip Thomas [mailto:thomas@act.sps.mot.com]
[...] ls -ld mail
drwxrwxrwt 3 root mail 16384 May 1 13:01 mail ^
Are you exporting the mail spool with root permission to your mail server?
From: Jason D. Kelleher [kelleher@susq.com]
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.
How about when the click the Done button? Is it possible that the mailtool is locking the inbox when they make changes to it, and not unlocking it until they commit the changes?
David Ritch
From: Philip Thomas [mailto:thomas@act.sps.mot.com]
[...] ls -ld mail
drwxrwxrwt 3 root mail 16384 May 1 13:01 mail ^
Are you exporting the mail spool with root permission to your mail server?
Yes.
-- Begin original message --
From: "David B. Ritch" dbritch@earthlink.net Date: Fri, 1 May 1998 22:24:19 -0400 Subject: RE: file locking problem To: "Philip Thomas" thomas@act.sps.mot.com, kelleher@susq.com Cc: toasters@mathworks.com
From: Philip Thomas [mailto:thomas@act.sps.mot.com]
[...] ls -ld mail
drwxrwxrwt 3 root mail 16384 May 1 13:01 mail ^
Are you exporting the mail spool with root permission to your mail server?
From: Jason D. Kelleher [kelleher@susq.com]
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.How about when the click the Done button? Is it possible that the mailtool is locking the inbox when they make changes to it, and not unlocking it until they commit the changes?
David Ritch
-- End original message --
---philip thomas
-
David B. Ritch -
Jason D. Kelleher -
Philip Thomas