Description of problem: This issue showed up in Fedora 9. I thought it would be fixed before Fedora 10. If a user has ever logged into a system it is remembered across reboots. Then some process is using that information to probe the users home directory which causes autofs to mount the home directory. Possible candidates are: hal-addon-storage scsi_eh gnome-settings-daemon The above process seem to run frequently. I have searched the entire file system but have not been able to find where the information is about the user so that we can determine which application is a fault. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: NFS server system /var/log/messages file: Dec 16 07:42:58 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:702 for /export/home/dhighley (/export/home) Dec 16 07:49:13 douglas mountd[2526]: authenticated unmount request from redwood.highley-recommended.com:962 for /export/home/dhighley (/export/home) Dec 16 07:49:14 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:785 for /export/home/dhighley (/export/home) Dec 16 07:55:28 douglas mountd[2526]: authenticated unmount request from redwood.highley-recommended.com:709 for /export/home/dhighley (/export/home) Dec 16 07:55:30 douglas mountd[2526]: authenticated mount request from redwood.highley-recommended.com:934 for /export/home/dhighley (/export/home)
What can I say, this isn't the first time difficulties like this have come up over the years. The sad fact is that if applications scan the file system without regard to the consequences and encounter autofs managed mounts autofs has no choice but to attempt to satisfy the request. This type of issue is one of the main reasons we log the pid of the requesting process when debug logging is enabled. You should be able to identify the process from this but sometimes the pid is that of a transient child process so it may not be quite that simple.
Thank you for the tip. Turning on debug revealed: Dec 16 20:03:20 redwood automount[8393]: expired /home/dhighley Dec 16 20:03:20 redwood automount[8393]: send_ready: token = 827 Dec 16 20:03:20 redwood automount[8393]: expire_cleanup: got thid 14041932134638 4 path /home stat 0 Dec 16 20:03:20 redwood automount[8393]: expire_cleanup: sigchld: exp 1404193213 46384 finished, switching from 2 to 1 Dec 16 20:03:20 redwood automount[8393]: st_ready: st_ready(): state = 2 path /h ome Dec 16 20:03:22 redwood automount[8393]: handle_packet: type = 3 Dec 16 20:03:22 redwood automount[8393]: handle_packet_missing_indirect: token 8 28, name dhighley, request pid 17193 Dec 16 20:03:22 redwood automount[8393]: attempting to mount entry /home/dhighle y Doing a ps -efl | grep 17193 led to /usr/libexec/gdm-simple-greeter. Removing execution permission and killing the process confirmed that automounter was no longer being asked to mount the home directory. So now how do we get control of gdm-simple-greeter so that it is not accessing automounted home directories? We see this is a duplicate bug now that the issue is understood. *** This bug has been marked as a duplicate of bug 456021 ***