Hi, I'm currently experiencing an issue on a large (several hundred) number of systems by which autofs mounts frequently become stale and don't trigger a mount. The automounts in question are NFS mounts. Based on the logs captured on a system that had debugging enabled umount appeared to timeout but did at some point succeed as evidenced by the fact that the mount in question isn't mounted after this issue occurs. (Why umount is taking so darned long is the subject of another investigation underway). I created what I believe to be a similar test situation in which the umount command doesn't complete within the autofs umount timeout value but does eventually succeed. Here are logs from autofs with debugging enabled on the test system, and the mount in question isn /net/nabl000/vol/blast: Nov 21 10:13:58 asktest1 automount[27418]: expiring path /net/nabl000/vol/blast Nov 21 10:13:58 asktest1 automount[27418]: handle_packet: type = 6 Nov 21 10:13:58 asktest1 automount[27418]: handle_packet_expire_direct: token 4829, name /net/nabl000/vol/blast Nov 21 10:13:58 asktest1 automount[27418]: st_expire: state 1 path /net Nov 21 10:13:58 asktest1 automount[27418]: umount_multi: path /net/nabl000/vol/blast incl 1 Nov 21 10:13:58 asktest1 automount[27418]: unmounting dir = /net/nabl000/vol/blast Nov 21 10:14:10 asktest1 automount[27418]: could not umount dir /net/nabl000/vol/blast Nov 21 10:14:10 asktest1 automount[27418]: couldn't complete expire of /net/nabl000/vol/blast Nov 21 10:14:10 asktest1 automount[27418]: dev_ioctl_send_fail: token = 4829 Nov 21 10:14:10 asktest1 automount[27418]: expiring path /net/nabl000/vol/blast Nov 21 10:14:10 asktest1 automount[27418]: handle_packet: type = 6 Nov 21 10:14:10 asktest1 automount[27418]: handle_packet_expire_direct: token 4830, name /net/nabl000/vol/blast Nov 21 10:14:10 asktest1 automount[27418]: umount_multi: path /net/nabl000/vol/blast incl 1 Nov 21 10:14:10 asktest1 automount[27418]: unmounting dir = /net/nabl000/vol/blast Nov 21 10:14:22 asktest1 automount[27418]: could not umount dir /net/nabl000/vol/blast Nov 21 10:14:22 asktest1 automount[27418]: couldn't complete expire of /net/nabl000/vol/blast Nov 21 10:14:22 asktest1 automount[27418]: dev_ioctl_send_fail: token = 4830 Nov 21 10:14:22 asktest1 automount[27418]: expiring path /net/nabl000/vol/blast Nov 21 10:14:22 asktest1 automount[27418]: handle_packet: type = 6 Nov 21 10:14:22 asktest1 automount[27418]: handle_packet_expire_direct: token 4831, name /net/nabl000/vol/blast Nov 21 10:14:22 asktest1 automount[27418]: umount_multi: path /net/nabl000/vol/blast incl 1 Nov 21 10:14:22 asktest1 automount[27418]: unmounting dir = /net/nabl000/vol/blast Nov 21 10:14:34 asktest1 automount[27418]: could not umount dir /net/nabl000/vol/blast Nov 21 10:14:34 asktest1 automount[27418]: couldn't complete expire of /net/nabl000/vol/blast Nov 21 10:14:34 asktest1 automount[27418]: dev_ioctl_send_fail: token = 4831 Once this occurs the autofs mount at /net/nabl000/vol/blast/ will not trigger a remount. Examining /net/nabl000/vol/blast using systemtap reveals that the dentry at /net/nabl000/vol/blast/ does not have the DMANAGED_AUTOMOUNT flag set on its dentry->d_mounted object the presence of which I believe is what causes follow_automount() in fs/namei.c to trigger an automount. If I set this flag on the d_mounted object of the dentry (again, using stap) then follow_automount is called, however in autofs4_d_automount the mount is not processed because the d_subdirs object of the dentry in question doesn't appear empty. What's interesting, however, is that if I kill -9 automount and repeat the process of setting the DMANAGED_AUTOMOUNT flag then list_empty(d_subdirs) evaluates to true. I can't quite figure this out (any insight would be appreciated). I suspect it has something to do with automount having /net/nabl000/vol/blast open(). As a workaround I can set UMOUNT_TIMEOUT to something arbitrarily high but it feels like a kludge. Should autofs be able to recover from timed out umounts that succeed? Any assistance would be greatly appreciated. Best regards, Aaron-- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
