Bug 476699

Summary:	Trashing of autofs caused by probe of user home directory
Product:	[Fedora] Fedora	Reporter:	David Highley <david.m.highley>
Component:	autofs	Assignee:	Jeff Moyer <jmoyer>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	ikent, jmoyer
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-12-17 04:35:58 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Highley 2008-12-16 16:14:59 UTC

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)

Comment 1 Ian Kent 2008-12-16 23:52:05 UTC

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.

Comment 2 David Highley 2008-12-17 04:35:58 UTC

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 ***