Bug 437246 - /net (auto.net) hangs with rawhide
/net (auto.net) hangs with rawhide
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-13 04:12 EDT by Jens Petersen
Modified: 2008-03-19 02:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-19 02:22:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jens Petersen 2008-03-13 04:12:33 EDT
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 07:47:28 EDT
Provide a debug log please.
Comment 2 Jens Petersen 2008-03-14 03:55:18 EDT
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 06:50:41 EDT
(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 07:26:36 EDT
(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 02:22:40 EDT
Thanks - not sure what the problem was (maybe selinux or something like that?)
but it is working fine now in recent rawhide.

Note You need to log in before you can comment on or make changes to this bug.