Date: Fri, 9 Jul 1999 12:00:52 -0700 (PDT) From: Doug <Doug@gorean.org> To: freebsd-hackers@freebsd.org Subject: more amd hangs Message-ID: <Pine.BSF.4.05.9907091142410.6982-100000@dt054n86.san.rr.com>
next in thread | raw e-mail | index | archive | help
In my continuing efforts to get this freebsd box into shape for
web hosting at my company (where it relies exclusively on NFS for
retrieving customer data) I've been making progress thanks to some recent
commits by Peter. Now I can run the heavy duty NFS access script and it
completes its mission about 2 out of 3 times. Also, now when it fails it
doesn't lock the whole box, just amd. Still not where I want it to be, but
it is definitely big progress. :)
What happens when it hangs is that amd becomes totally wedged. I
cannot do 'df' or 'ls /' at all (the amd mountpoints are on /), and
killing the amd process is no help; I have to reboot the box. Ktrace'ing
amd at this point gets me nothing. The ktrace process just dies and leaves
a 0 byte ktrace.out file. (BTW, I am also still having problems with
ktrace exiting while the process is still running when I actually get it
to attach, if anyone cares.)
The one thing that I was able to do recently was to get amq to
dump a core file. I tried running amq while the amd process was wedged and
when it didn't return I killed it with a ^\ command. The trace was kind of
interesting:
Core was generated by `amq'.
Program terminated with signal 3, Quit.
Reading symbols from /usr/lib/libc.so.3...(no debugging symbols
found)...done.
Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols
found)...
done.
#0 0x28098f3c in select () from /usr/lib/libc.so.3
(gdb) where
#0 0x28098f3c in select () from /usr/lib/libc.so.3
#1 0x280afd33 in clnttcp_create () from /usr/lib/libc.so.3
#2 0x280b4eb0 in xdrrec_endofrecord () from /usr/lib/libc.so.3
#3 0x280b4efc in xdrrec_endofrecord () from /usr/lib/libc.so.3
#4 0x280b4f63 in xdrrec_endofrecord () from /usr/lib/libc.so.3
#5 0x280b4a91 in xdrrec_create () from /usr/lib/libc.so.3
#6 0x280b49d7 in xdrrec_create () from /usr/lib/libc.so.3
#7 0x280b8b6c in xdr_u_int32_t () from /usr/lib/libc.so.3
#8 0x280b539b in xdr_replymsg () from /usr/lib/libc.so.3
#9 0x280af90e in clnttcp_create () from /usr/lib/libc.so.3
#10 0x804a189 in xdr_u_short ()
#11 0x8049aba in xdr_u_short ()
#12 0x8049209 in xdr_u_short ()
I'm not sure exactly what that means, but I still have the core
file so if anyone wants to look into this I'll be glad to do what I can.
The amd conf files are below, any insights or suggestions welcome.
Doug
--
On account of being a democracy and run by the people, we are the only
nation in the world that has to keep a government four years, no matter
what it does.
-- Will Rogers
amd.conf:
[ global ]
# Only search for maps of this type
map_type = file
# Search this path for maps
search_path = /etc
# Use this directory for amd's private mount points
auto_dir = /usr/amdmount
# How long the mounts should live, in seconds
#cache_duration = 1800
# Log all activity to syslog (daemon)
log_file = syslog:local7
log_options = all
# Check /etc/hosts for hostnames
normalize_hostnames = yes
# Lock the amd process into memory, improves perf.
plock = yes
# Use the special /default entry in maps
selectors_on_default = yes
# DEFINE AN AMD MOUNT POINT
[ /Interfaces ]
map_name = amd.Interfaces
[ /Hold ]
map_name = amd.Hold
amd.Interfaces:
/defaults type:=nfs;opts:=rw,vers=2,intr,proto=udp,noconn
* rhost:=IP${key};rfs:=/Space/${key}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9907091142410.6982-100000>