1

I have a set of mount points which I use autofs to access. They have been around for quite some time, and in systems I've inherited running CentOS6 admins before me have implemented cronjobs restarting autofs conditionally if certain mountpoints are missing.

I've started setting up new CentOS7 systems using the same mountpoints and even though the autofs setup is brand new with new versions of everything and sssd replacing traditional ldap lookups and such autofs is still showing the same symptoms.

The problems I see are not in /net but other than that this very old issue on redhat seem to be very similar to mine. Downgrading as suggested in the article is unfortunately not an option as CentOS7.5 only have 1 version of autofs (namely 5.0.7-83.el7) in the repos.

The mount points are available to autofs in such a way that I can query automount and get the proper record back:

# automount -m sss auto_projects | grep project1
project1    /subproj1 -noatime nfsserver:/volum/proj1_subproj1 /subproj2 -noatime nfsserver:/volum/proj1_subproj2 /subproj3 -noatime nfsserver:/volum/proj1_subproj3 /subproj4 -noatime nfsserver:/volum/proj1_subproj4 /subproj5 -noatime nfsserver:/volum/proj1_subproj5

When autofs is freshly started everything works as it should, I can browse /projects/project1 and see subproj1 through 5.

After a little while (sometimes hours, sometimes days) however if I do ls in /projects/project1 only one of the subprojs is still there. Trying to cd into any of the other folders (to trigger a mount) renders -bash: cd: subprojX: No such file or directory.

In the logs I'll see automount logging rows like:

expiring path /projects/project1
umount_multi: path /projects/project1 incl 1
umount_multi_triggers: umount offset /projects/project1/subprojX
umount_autofs_offset: offset /projects/project1/subprojX not mounted
rmdir_path: lstat of subprojX failed
[... more subprojs ...]
some offset mounts still present under /projects/project1
couldn't complete expire of /projects/project1
dev_ioctl_send_fail: token = 853
1 remaining in /projects

If I don't start autofs with the --force option to automount I will not be able to recover from this. A systemctl restart autofs will hang and time out. With the --force option the service is restartable and will recover the mountpoints until they vanish again.

Mounting manually works as expected.

I think this is a bug in autofs, but I need help pinpointing / proving that. And perhaps also some help in creating a bug report...

How can I cure autofs from its apparent dementia?

0

You must log in to answer this question.

Browse other questions tagged .