Bug 437246

Summary:	/net (auto.net) hangs with rawhide
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	autofs	Assignee:	Ian Kent <ikent>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	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-03-19 06:22:40 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 Jens Petersen 2008-03-13 08:12:33 UTC

Description of problem:
Access nfs mounts via /net seems to hang under current rawhide,
even with permissive selinux.

Version-Release number of selected component (if applicable):
autofs-5.0.3-6

How reproducible:
every time

Steps to Reproduce:
1. install rawhide
2. ls /net/my.file.server/network/mntpoint
  
Actual results:
2. hangs

Expected results:
2. listing of public nfs dir

Additional info:
I think this has probably been happening for a while.

Comment 1 Ian Kent 2008-03-13 11:47:28 UTC

Provide a debug log please.

Comment 2 Jens Petersen 2008-03-14 07:55:18 UTC

I think it is very easy to reproduce with a rawhide install.

Here is a gdb backtrace from automount:

#0  0x00131416 in __kernel_vsyscall ()
#1  0x00140320 in __sigwait (set=<value optimized out>, sig=<value optimized
out>) at ../sysdeps/unix/sysv/linux/sigwait.c:63
#2  0xb803c08c in main (argc=0, argv=0xbf867588) at automount.c:1332

After continuing the process in gdb later it finally ended and after restarting
the autofs service by hand, nfs automount starting working.

Comment 3 Ian Kent 2008-03-14 10:50:41 UTC

(In reply to comment #2)
> I think it is very easy to reproduce with a rawhide install.

Why should the Rawhide install make a difference or are
you saying this isn't an autofs problem.

> 
> Here is a gdb backtrace from automount:
> 
> #0  0x00131416 in __kernel_vsyscall ()
> #1  0x00140320 in __sigwait (set=<value optimized out>, sig=<value optimized
> out>) at ../sysdeps/unix/sysv/linux/sigwait.c:63
> #2  0xb803c08c in main (argc=0, argv=0xbf867588) at automount.c:1332
> 
> After continuing the process in gdb later it finally ended and after restarting
> the autofs service by hand, nfs automount starting working.

This is just the signal handling thread and is nothing
to do with the auto mounting activity.

If you're having a problem with autofs then provide a debug
log otherwise please close the bug.

Ian

Comment 4 Ian Kent 2008-03-14 11:26:36 UTC

(In reply to comment #3)
> If you're having a problem with autofs then provide a debug
> log otherwise please close the bug.

That was a bit short, Sorry.

Fact is I'm not able to reproduce this with the current
Rawhide package, but that is on an F8 install. I did also
try to install Rawhide into a VM but I'm having some
difficulty so I can't do that at the moment.

I checked using the auto.net script and the "-hosts" map
type, which is what you should be using nowadays by the way.
Both worked fine.

When I can't duplicate a problem the normal procedure is
to obtain a debug log. In fact I generally want one even
if I can reproduce the issue to make sure that what I'm
seeing is in fact the same as the report.

It's not that difficult to get one, just have a quick look
at http://people.redhat.com/jmoyer so you don't miss
anything.

Ian

Comment 5 Jens Petersen 2008-03-19 06:22:40 UTC

Thanks - not sure what the problem was (maybe selinux or something like that?)
but it is working fine now in recent rawhide.