T.R | Title | User | Personal Name | Date | Lines |
---|
640.1 | | NNTPD::"[email protected]" | Fernando Fraticelli | Mon Apr 28 1997 17:20 | 8 |
| This popup is created due to a bad stat of the folder, or it cannot
open it. I have found a problem with NFS in where the file handle data
is stale. I have a fix for Steel. If you are running NFS and need a
patch, let me know what version you need it for. I'll try to provide
you with one.
Fernando
[Posted by WWW Notes gateway]
|
640.2 | Here's the mailhub change info... | DECC::SULLIVAN | Jeff Sullivan | Mon Apr 28 1997 17:27 | 44 |
| Date: Wed, 23 Apr 1997 12:41:09 -0400
From: Debbie Smith USG <dasmith>
To: [email protected]
Subject: Mail on Quarry Transitioning to Mailhub, Monday, April 28th at 6:00AM
Hi,
It has been a long standing goal of the admin group to implement
a mailhub strategy for mail delivery in the production environment.
As a part of this process we will be mounting /var/spool/mail
to each of the PE servers from mailhub, the ASE mail server dedicated to
mail delivery and distribution. The ASE mail server is comprised of two
systems, mailhub1 and mailhub2, with a service named mailhub. Our move
to a centralized mailhub allows us to guarantee high availability for
mail. This means that even if the system where your home directory
resides is down, mail will be delivered.
The change should be transparent to you; mail, including DECnet mail,
will be addressed and delivered exactly as it is now. Your PE alias
will change from user@{quarry|rock} to user@mailhub, but that is an
administrative change on our end, not one that you need to do anything
about.
I will be making this change on QUARRY starting at 6AM on
Monday, April 28th; QUARRY will be back up with the new
mail configuration by 7AM. There will be a copy of your old
/var/spool/mail/<user> file in /var/spool/mail-local/<user> for a couple
of weeks if you'd like to compare your old file on QUARRY and
its copy on /var/spool/mail/<user> mounted from mailhub.
Note to biff users, biff will not work because the QUARRY will not be
processing any incoming mail and that is what biff keys off when mail
is sent. We have provided a script, /contrib/bin/biff.sh (written by
John Dustin), that emulates some of the biff functionality. Just
run it on QUARRY and it will notify you when new mail arrives.
Thanks.
--
Mark Angel TCP/IP: [email protected]
Digital Equipment Corporation DECnet: wasted::angel
110 Spit Brook Road, ZKO3-3/V08 Voice: 1-603-881-1160
Nashua, NH 03062-2698 FAX: 1-603-881-2257
|
640.3 | I think I need a patch! | DECC::SULLIVAN | Jeff Sullivan | Wed Apr 30 1997 13:39 | 18 |
| I'm currently on V4.0, but hope to go to V4.0B sometime pretty soon and PTmin
eventually. I'd be very willing to try out a new dtmail (hopefully I'd need
nothing else).
I have been missing some mail since the mailhub change and it doesn't seem to
bounce back. Could this be do to dtmail being in a state where this popup is up?
I noticed that it comes up when checking mail and this freezes my dtmail session
(hourglass up) until I acknowledge it. It sometimes gets into this state when
doing a "Check for new mail" or an automatic update (but not always).
If you have a public web/ftp patch available, you can post the info here. Or
feel free to contact me offline, if you'd rather not make it public.
Thanks,
-Jeff
|
640.4 | DtMail losing mail on NFS mounted dir | DECC::SULLIVAN | Jeff Sullivan | Thu May 01 1997 15:54 | 34 |
| I'm convinced that DtMail is losing mail with this new setup. That is, a NFS
mounted /var/spool/mail directory on my production machine. Previously, the mail
was physically delivered to that machine. I have been reading/writing mail on
that machine throughout.
Here's what appears to be happening:
- dtmail does a "checking for new mail" and hangs. The popup comes up.
At this point, I believe that new mail has arrived.
- I acknowledge the popup and then dtmail does an "auto save"
The autosave overwrites the incoming mail.
I have verified that new mail exists between steps one and two with another
mailer. After step two, the new mail is gone. I am willing to file a qar on this
if the problem is reproducible.
As a workaround, I'll use another mailer for the time being.
Is it possible to
a) run dtmail remotely (via -host ... ) so that I can try out the dtmail_v40
that I copied? I don't have the authority to install it on my production
machine.
b) forward my mail from the mailhub to the machine I read mail on?
Someone suggested a .maildelivery file, but that doesn't seem to work.
I use a .forward file to do mail filtering
Let me know if you have ideas.
Thanks,
-Jeff
|
640.5 | | CFSCTC::SMITH | Tom Smith MRO1-3/D12 dtn 297-4751 | Fri May 02 1997 02:25 | 9 |
| NFS-mounted spool directories are not a good idea, to make an
admittedly sweeping and opinionated generalization. The problem is with
file locking. Different clients and MTAs use different locking schemes,
often incompatible, and NFS file locking has never been known for its
outstanding reliability anyway.
Whether that explains these particular problems, I can't say.
-Tom
|
640.6 | Not my choice... | DECC::SULLIVAN | Jeff Sullivan | Fri May 02 1997 11:20 | 12 |
| Moving the mail spool to a NFS mounted directory was not my choice. These are
the types of decisions made by sysadmins everywhere. Normal users don't have a
choice in that case. I would expect at least some Digital UNIX customers to do
this.
The point is that the change was made group-wide and I know of people using exmh
and dxmail that did not run into the problem I've seen. My only recourse has
been to switch back to mailx/xbiff for the time being.
-Jeff
|
640.7 | | NNTPD::"[email protected]" | Fernando Fraticelli | Fri May 02 1997 14:31 | 19 |
|
You can copy the new dtmail binary to your home directory and have the admin
personell change the permissions for you. If this solves your problem, you can
have them replace the system copy with this new one.
As far as NFS mounting spool file, all of DU's base mail components work
accross
NFS. We have made sure that from the mail point of view this works. If the NFS
servers happen to become unavailable, our applications will timeout and not
try
to use nfs locking.
This problem is a unique problem to dtmail. Thats why you
don't see this with other mail applications. This copy solves the problem you
are having which is related to stale NFS file handles.
5/1/97
Fernando Fraticelli
[Posted by WWW Notes gateway]
|
640.8 | Beta testing dtmail_v40.... | DECC::SULLIVAN | Jeff Sullivan | Fri May 02 1997 16:41 | 14 |
| I got the admin to change the persmisions and am now running dtmail_v40. She
said that others had run into problems and she would be willing to install this
fix on our production machines, if it resolves the problem.
I've tried exmh and netscape mail. I actually like some features on nsmail, but
I don't like the fact that it doesn't use my .mailrc for things like aliases and
it doesn't keep a single mailrecord file (messages sent are entered in a "Sent"
folder).
I'll let you know how this one works.
Do you want a QAR for this problem or is it already covered in PTmin/Steel?
Thanks,
-Jeff
|
640.9 | "network aware mail file locking" ? | DECC::SULLIVAN | Jeff Sullivan | Fri May 02 1997 17:00 | 11 |
| The sysadmin said that they turned off "network aware mail file locking" to work
around their NFS problem. This did not work for me, nor did it seem intuitive to
me that this would resolve such a problem.
In any case, it was ON by default and I now have it turned OFF. Is this the
right thing to do in our case?
I have not seen the problem since bringing up the new dtmail.
Thanks,
-Jeff
|
640.10 | Dtmail_v40 and NFS | NNTPD::"[email protected]" | Fernando Fraticelli | Mon May 05 1997 10:46 | 17 |
| You want to turn off network aware file locking, not for this reason, but
because of tooltalk. DtMail, as well as all CDE applications, make use of
tooltalk for interprocess communication. One feature of tooltalk is to watch
for access to the users folders. If tooltalk is not running on all systems,
you may have problems. Hence the reason for disabling this feature. This does
not change the bahavior of dtmail. All locking is done whether tooltalk is
enabled or disabled.
You don't have to submitt a QAR on this. One already exists in the database.
Keep me posted as to how this works out. If you are comfortable with it, you
can tell your admin to replace the system version with this one. I will make
sure the fix goes in for steel and other support pools.
5/5/97
Fernando Fraticelli
[Posted by WWW Notes gateway]
|
640.11 | Patched dtmail installed on quarry | DECC::SULLIVAN | Jeff Sullivan | Wed May 07 1997 11:45 | 27 |
| The patched dtmail was installed on our production machine (quarry) and appears
to have fixed the problems I was seeing. I'm back to using dtmail full-time now.
Note that we have also turned off network aware file locking.
Since this has been qared and will be resolved in Steel and the appropriate PT
pools, I think this issue is resolved.
Thanks for the fixes...
-Jeff
Date: Mon, 5 May 1997 13:33:16 -0400
From: Debbie Smith USG <dasmith>
To: [email protected]
Subject: new dtmail binary on Quarry
Cc: dasmith, [email protected]
There is a new dtmail binary in place on quarry which has a
fix for a NFS - stale file handle data problem.
Please also make sure to turn OFF 'network aware file locking'
under mail options when using dtmail.
Thank you,
Debbie
|