Bad symlinks are presented when multiple programs try to open filesystems controlled by amd. The correct nfs filesystems are mounted but the links created in the virutal filesystem are mixed up. lrwxrwxrwx 1 root wheel 52 Aug 7 10:40 /home/dhutches -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/prog/dhutches lrwxrwxrwx 1 root wheel 48 Aug 7 10:40 /home/dstevens -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/jpr lrwxrwxrwx 1 root wheel 52 Aug 7 10:40 /home/grh -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/prog/dhutches lrwxrwxrwx 1 root wheel 48 Aug 7 10:40 /home/jlgibson -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/grh lrwxrwxrwx 1 root wheel 53 Aug 7 10:40 /home/jpr -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/jlgibson lrwxrwxrwx 1 root wheel 52 Aug 7 10:40 /home/oconnor -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/prog/dstevens lrwxrwxrwx 1 root wheel 52 Aug 6 04:28 /home/okumoto -> /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/okumoto jsoefs:/vol/vol0/unix/home/de/staff/okumoto 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/okumoto jsoefs:/vol/vol0/unix/home/de/prog/dhutches 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/prog/dhutches jsoefs:/vol/vol0/unix/home/de/staff/grh 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/grh jsoefs:/vol/vol0/unix/home/de/staff/jlgibson 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/jlgibson jsoefs:/vol/vol0/unix/home/de/staff/jpr 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/jpr jsoefs:/vol/vol0/unix/home/de/prog/dstevens 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/prog/dstevens jsoefs:/vol/vol0/unix/home/de/staff/oconnor 221987 200502 21484 90% /.amd_mnt/jsoefs/vol/vol0/unix/home/de/staff/oconnor How-To-Repeat: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx % cat /etc/amd.conf # GLOBAL OPTIONS SECTION [ global ] browsable_dirs = no map_type = nis auto_dir = /.amd_mnt #cache_duration = 300 cache_duration = 60 # make things break faster. #debug_options = all log_file = /var/log/amd log_options = all pid_file = /var/run/amd.pid plock = yes print_pid = yes print_version = no restart_mounts = yes selectors_on_default = yes unmount_on_exit = yes # DEFINE AN AMD MOUNT POINT [ /home ] map_name = amd.home xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx % pcat amd.home /defaults opts:=dev,grpid,intr,nosuid,proto=tcp,quota,resvport,rw,soft,vers=3 dhutches type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/prog/${key} dstevens type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/prog/${key} grh type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/staff/${key} jlgibson type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/staff/${key} jpr type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/staff/${key} oconnor type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/staff/${key} okumoto type:=nfs;rhost:=jsoefs;rfs:=/vol/vol0/unix/home/de/staff/${key} xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx #!/bin/sh while true; do echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX df -t nfs | grep jsoefs ls -l /home/ echo YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY for i in dhutches dstevens grh jlgibson jpr oconnor okumoto; do cat /home/$i/.cshrc > /dev/null & done df -t nfs | grep jsoefs for i in dhutches dstevens grh jlgibson jpr oconnor okumoto; do ls -l /home/$i done sleep 300 done exit 0
Responsible Changed From-To: freebsd-bugs->mbr Take this PR.
State Changed From-To: open->feedback Hi, Is this still a problem with latest am-utils ?
I can confirm that this is still an issue on a machine running 8.1-RELEASE. It's a sporadic, inconsistent problem. It seems likely it's related to this: http://www.am-utils.org/docs/am-utils/attrcache.txt
State Changed From-To: feedback->open Confirmed as of 2011.
Responsible Changed From-To: mbr->freebsd-bugs commit bit has been taken in for safekeeping.
Still happening on FreeBSD 9.3-RELEASE.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
Is this PR still relevant? AFAICT amd(8) had been phased out in favor of autofs(5) since at least 2015 and finally retired more than two years ago. Does autofs(5) exhibit this (or similar) problem?
amd(8) was retired in 2020. See autofs(5) for its replacement.