Hello Ian, et al. Using autofs-5.0.3-36 (built from Fedora 10 updates source RPM) on 2.6.26.6-49.fc8 kernel. We run w/ LOGGING=debug.
We use autofs extensively for NFS multimounts and there are a few issues that we're trying to get resolved: Problem #1: We us a TIMEOUT of 300 but there are often mounts that are never expired, even if lsof shows no process is using the mount points in question. kill -USR1 doesn't help. Example: /net/bb2 isn't expiring. Relevant portion of /proc/mounts: bb2:/ /net/bb2 nfs rw,nosuid,nodev,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=udp,addr=192.168.95.79 0 0 -hosts /net/bb2/acl autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 -hosts /net/bb2/home autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 -hosts /net/bb2/opt autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 -hosts /net/bb2/tmp autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 -hosts /net/bb2/usr autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 -hosts /net/bb2/var autofs rw,relatime,fd=12,pgrp=9397,timeout=300,minproto=5,maxproto=5,offset 0 0 bb2:/opt /net/bb2/opt nfs rw,nosuid,nodev,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nointr,proto=tcp,timeo=600,retrans=2,sec=sys,mountproto=udp,addr=192.168.95.79 0 0 Sample log entry: Feb 17 15:31:40 gemini automount[9397]: handle_packet_expire_indirect: token 67811, name bb2 Feb 17 15:31:40 gemini automount[9397]: expiring path /net/bb2 Feb 17 15:31:40 gemini automount[9397]: umount_multi: path /net/bb2 incl 1 Feb 17 15:31:40 gemini automount[9397]: some offset mounts still present under /net/bb2 Feb 17 15:31:40 gemini automount[9397]: couldn't complete expire of /net/bb2 Feb 17 15:31:40 gemini automount[9397]: send_fail: token = 67811 Interestingly, there's no mention of /net/bb2/opt, which it would need to umount first. Problem #2: One of the multimounts is misbehaving and not lazy-mounting. The problem seems to stem from a failure to do a lazy umount earlier: Log entries for the umount attempt: Feb 17 13:32:54 gemini automount[9397]: handle_packet: type = 4 Feb 17 13:32:54 gemini automount[9397]: handle_packet_expire_indirect: token 67564, name cobweb Feb 17 13:32:54 gemini automount[9397]: expiring path /net/cobweb Feb 17 13:32:54 gemini automount[9397]: umount_multi: path /net/cobweb incl 1 Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset /net/cobweb/home/ftp Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset /net/cobweb/home/ftp not mounted Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset /net/cobweb/home/patches Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset /net/cobweb/home/patches not mounted Feb 17 13:32:54 gemini automount[9397]: umount_multi_triggers: umount offset /net/cobweb/www/sites/franzdownload Feb 17 13:32:54 gemini automount[9397]: umount_autofs_offset: offset /net/cobweb/www/sites/franzdownload not mounted Feb 17 13:32:54 gemini automount[9397]: some offset mounts still present under /net/cobweb Feb 17 13:32:54 gemini automount[9397]: couldn't complete expire of /net/cobweb Feb 17 13:32:54 gemini automount[9397]: send_fail: token = 67564 After this happened, accesses to /net/cobweb/home/ftp did not result in an automatic mount, just an empty directory. This is a production system so I can only do so much, but I can try reasonable tests and supply debugging output. Unfortunately I haven't yet found a way to explicitly cause the broken scenario to happen. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs
