Bug 443505

(In reply to comment #0)
> Description of problem:
> 
> the TIMEOUT variable in /etc/syconfig/autofs is ignored

You must be mistaken somehow, I use this a lot without problem.

> 
> Version-Release number of selected component (if applicable):
> 
> autofs-5.0.3-11.i386
> Fedora release 8.93 (Rawhide)
> 
> How reproducible:
> 
> Access /net/$some_host/$some_exported_directory/.
> TIMEOUT is set to 200 in /etc/sysconfig/autofs by default, but the directory is
> never unmounted again (lsof shows no open files under /net).

I think you'll find that's 300.

> However, setting OPTIONS="-t 20" in /etc/sysconfig/autofs works (mounted
> directories are now unmounted after 20 seconds).

As I said above, there must be something else causing
this behavior. We'll need to got more information.

> 
> I'm not sure if autofs is supposed to honour the $TIMEOUT environment variable,
> or if the init script is supposed to turn it into the corresponding "-t
> $TIMEOUT" option (it does not, it just sources /etc/sysconfig/autofs and appends
> $OPTIONS to the autofs command).

autofs does use the TIMEOUT configuration entry but it
doesn't get it from the environment, it gets it directly
from the configuration file.

How about posting the output of "showmount -e <server>"
and /etc/exposts for a host you've had problems with.

A debug log is also essential. 
Please check http://people.redhat.com/jmoyer for details
on how this is can be done.

Ian

Created attachment 303364 [details]
autofs debug log with OPTIONS="-t 10" set in /etc/sysconfig/autofs

Created attachment 303365 [details]
autofs debug log with TIMEOUT=10 set in /etc/sysconfig/autofs

Hi Ian,
you're right, the problem is not that the timeout is not being read. I made some
debug logs as you suggested, and the timeout value shows up in the log in both
cases. But the behaviour is still different.

Here is the information you requested:

# showmount -e 192.168.0.1
Export list for 192.168.0.1:
/data   drow.example.net
/backup drow.example.net

The server's /etc/exports (the server is running CentOS 4.6 with the latest
updates):
/data drow(rw,no_root_squash,sync)
/backup drow(ro,root_squash,sync)

For the two attached logs, I did the following: stop autofs, umount the exported
directories if necessary, restart autofs. Then I ran 'ls' on a couple of files
in the exported directories.

In the first case, everything was unmounted after 10 seconds, in the second case
not (Unfortunately, the logs contain lots of garbage lookups for ".Trash"
directories, possibly from Gnome(?), but these don't seem to hurt).

Let me know if I you need more information.

(In reply to comment #4)
> Hi Ian,
> you're right, the problem is not that the timeout is not being read. I made some
> debug logs as you suggested, and the timeout value shows up in the log in both
> cases. But the behaviour is still different.

Yes, there's something odd going on.
Those file descriptor errors need attention.
Could you do something else for me please.

After you see these errors save a copy of /proc/mounts
and get a gdb backtrace of the threads of the running
automount program. You'll need to install the matching
autofs-debuginfo package for this to be meaningful.

gdb -p <automount pid> /usr/sbin/automount
gdb> thr a a bt

save and post the output.

> 
> Here is the information you requested:
> 
> # showmount -e 192.168.0.1
> Export list for 192.168.0.1:
> /data   drow.example.net
> /backup drow.example.net
> 
> The server's /etc/exports (the server is running CentOS 4.6 with the latest
> updates):
> /data drow(rw,no_root_squash,sync)
> /backup drow(ro,root_squash,sync)

Completely standard, these should be no problem at all.

> 
> For the two attached logs, I did the following: stop autofs, umount the exported
> directories if necessary, restart autofs. Then I ran 'ls' on a couple of files
> in the exported directories.
> 
> In the first case, everything was unmounted after 10 seconds, in the second case
> not (Unfortunately, the logs contain lots of garbage lookups for ".Trash"
> directories, possibly from Gnome(?), but these don't seem to hurt).

Yes, that will be the GUI.
It's annoying but there's not much we can do about it.

Ian

OK, sorry for the confusion. The behaviour seems to be unrelated to the timeout
setting after all. Instead, the problem is triggered whenever an exported 
directory is mounted for the 2nd time.

I commented out one of the lines in /etc/exports on the server and ran more 
tests: when I access the exported directory for the first time, it is *always*
cleanly unmounted after 10 seconds. When I access the same directory a 2nd
time, the directory is mounted again, but now is "stuck". I get the "bad file
descriptor" errors in the debug log immediately after the directory is
re-mounted, even before the timeout expires.

The reason I did not find out earlier was that I a) restarted autofs between 
every test run, and b) I had two exports enabled. Every access would result in
both of them being mounted, and sometimes this would trigger the bug and
sometimes not.

Created attachment 303670 [details]
copy of /proc/mounts after mount gets "stuck"

Created attachment 303671 [details]
gdb backtrace of autofs after mount got "stuck"

(In reply to comment #8)
> Created an attachment (id=303671) [edit]
> gdb backtrace of autofs after mount got "stuck"
> 

You sure this is when you're system is wedged?
This looks totally normal and shows autofs isn't waiting for
anything to complete.

(In reply to comment #7)
> Created an attachment (id=303670) [edit]
> copy of /proc/mounts after mount gets "stuck"
> 

Also completely normal.
Two autofs trigger mounts and two mounts on top of them.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.