I believe the problem just reported is either an Apache httpd problem, OR
an NFS problem, or a combination of both. I'd like however to inquire whether
this is a known bug with Tru 5.0.
On Tue, 3 Oct 2000, Lucio Chiappetti wrote:
> A colleague with an Alpha with Tru64 5.0 (managed separately from my three
> with DU 3.2) is occasionally experiencing the following console messages (they
> appear also in /var/adm/messages and in syslog.date kern.log where they are
> prefixed with vmunix.
>
> svcktcp_send : xdr_replymsg failed
> rfs_dispatch : sendreply failed IP address : x.y.z.t
>
> where x.y.z.t is the IP address of our institute DNS, NIS master and main NFS
> server (which is a Sun).
We have been able to reproduce the problem, and also to work around it. Here
follows the explanation :
a) our Sun is our primary WWW server.
Therefore a request of
http://www.ifctr.mi.cnr.it/~user/personal.html
- first goes via http to the Sun
- the Sun interrogates itself via NIS and translates ~user in something
like /machine/user (our user homes are on NFS clients)
- the Sun automounts disk /machine ( machine:/machine)
and finally serves the request
b) the user under question has home on his own Alpha (machine = alpha1)
That's the same as me, I also have home on my own Alpha (say, alpha2)
c) both Alphas are ALSO "project" httpd servers. Therefore it would be
MORE EFFICIENT to access them directly, say as
http://alpha1/~user1 pr
http://alpha2/~user2
but is not forbidden to use the form
http://www.../~user
actually this works fine for me. I usually access both my project and
personal pages directly on my Alpha via http. People from outside also
access project pages directly (the institute WWW has also Redirect
directives to force that), but occasional links may be in the form
http://www.../~user. They do work (the Sun may not process automatically
some shtml directives in plain html files because unlike my Alpha is
not instructed to do so, but such accesses DO NOT CRASH the Sun)
d) An access of the form
http://www.../~user1 where user1 is on Alpha1
instead "crashes" the Sun. It was difficult to correlate it with
activities on the Alpha because the request can come from anywhere
(actually the user was doing it from a PC). The symptom is :
- Sun receives the httpd request
- Sun tries to automount the Alpha disk
- at this point there is some handshake problem :
- on the Sun lots of NFS errors "alpha server not responding"
"alpha server OK" in a tight loop
- on the Alpha the quoted console messages
- after 20-60 sec something saturates on the Sun, and ypbind starts
giving error messages
e) our workaround has been to put in the Sun's http configuraiton file
a Redirect directive Redirect ~user1
http://alpha1.../~user1
This forces to go directly to the Alpha and avoid automount
f) Note that automount Sun->Alpha works perfectly if at shell level on
the Sun we do anything like ls ~user1 !
The curious thing of all this is that there is NO PROBLEM between the Sun
(solaris 2.5.1 and Apache/1.3b3) and my "old" Alpha (DU 3.2 and NCSA httpd
!!!), while the problem is there between the Sun and the "new" Alpha (Tru64
5.0 and Apache 1.3.12).
Anybody knows if this is a "dangerous combination" ?
----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)
----------------------------------------------------------------------------
"This land .. is my land .. e no xe una portaerei"
[English in the original] [and is not an aircraft carrier]
M.Paolini - I cani del gas - Bestiario italiano
----------------------------------------------------------------------------
For more info :
http://www.ifctr.mi.cnr.it/~lucio/personal.html
----------------------------------------------------------------------------
Received on Tue Oct 03 2000 - 10:15:55 NZDT