Bug 17844

Summary: Amd wedges every morning since I've upgraded to 4.0
Product: Base System Reporter: durian <durian>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-STABLE   
Hardware: Any   
OS: Any   

Description durian 2000-04-07 15:20:01 UTC
	Every morning since I've upgraded to 4.0 (cvsupped on the 31st),
	amd is in a wedged state.  When I try to access my home directory
	via /u/durian (where /u is a symbolic link to /home/fserver - a
	directory managed by amd) amd reports that /u/durian isn't
	responding.  The actual NFS directory containing the homes is
	still mounted and I can access my home directory.  Just not via
	amd.  If I kill amd and restart it, things are good to go again.

	I think this is related to NFS as I also get messages saying
	the NFS server wasn't responding during the night:

Apr  6 22:38:51 lostwax /kernel: nfs server fserver:/export/home/fserver: not re
sponding
Apr  6 22:47:12 lostwax /kernel: receive error 60 from nfs server fserver:/expor
t/home/fserver
Apr  7 05:59:30 lostwax /kernel: nfs server fserver:/export/home/fserver: is ali
ve again
Apr  7 06:11:02 lostwax /kernel: receive error 60 from nfs server fserver:/expor
t/home/fserver

	I don't know what is going on at 6:00am, but there is a cron job
	running at 22:00 that does backups - including rdumps.

	So my gut feeling is that NFS goes out to lunch when the rdump
	is going on (a separate bug I suppose) and this confuses amd.
	NFS eventually comes back, but not in time for amd.

	I do have a number of warning from amd at start-up.  Perhaps that
	is the problem.  Here are our amd_flags:

	amd_enable="YES"
	amd_flags="-a /export           \
	        -d cellport.com         \
	        -c 1800                 \
	        -l syslog               \
	        -r                      \
	        -x fatal,error,user     \
	        /home /etc/amd.home     \
	        /amd /etc/amd.amd

	/etc/amd.home:
	# amd.home

	/defaults       -type:=nfs;rfs:=${autodir}${path};rhost:=${key};\
	                fs:=${autodir}${path};\
	                opts:=rw,grpid,timeo=10,retrans=5,nosuid,intr,\
	                utimeout=1200,rsize=8192,wsize=8192
        
	fserver         host==${key};type:=link || \
	                        ;
	lostwax         host==${key};fs:=/usr/home;type:=link || \
	                rhost:=${key};rfs:=/usr/home
	                        ;


	/etc/amd.amd:
	# amd.amd

	/defaults	-type:=nfs;rfs:=${autodir}${path};rhost:=${key};\
			fs:=${autodir}${path};\
			opts:=rw,grpid,timeo=10,retrans=5,nosuid,intr,\
			utimeout=1200,rsize=8192,wsize=8192

	applix		host==lostwax;fs:=/disk2/applix;type:=link || \
			rhost:=lostwax;rfs:=/disk2/applix
				;
	distfiles	host==fserver;fs:=/usr/ports/distfiles;type:=link || \
			rhost:=fserver;rfs:=/usr/ports/distfiles
				;
	src		host==fserver;fs:=/usr/local/src;type:=link || \
			rhost:=fserver;rfs:=/usr/local/src
				;
	doc		host==fserver;fs:=/usr/local/www/doc;type:=link || \
			rhost:=fserver;rfs:=/usr/local/www/doc
				;


	Please let me know if you would like system configuration
	details on our server.  Lostwax is my desktop machine.

Fix: 

No known fix.
How-To-Repeat: 
	I'm not sure how easily this can be reproduced outside our
	environment, though it is consistent here.  I guess you need to
	set up NFS, amd and some backup cron job much like what we
	have here.
Comment 1 Mike Barcroft freebsd_committer freebsd_triage 2001-07-22 02:12:46 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-25 16:57:49 UTC
State Changed
From-To: feedback->closed


Originator confirms the problem has been solved in newer versions of 
FreeBSD.