Verified... The thread is hung up in do_expire waiting on a thread signal (sig_wait) probably from umount_multi...
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Biggs > Sent: Thursday, June 19, 2008 10:59 AM > To: [email protected] > Cc: Ian Kent > Subject: [autofs] Automounter stops mounting home directories. > > [EMAIL PROTECTED] root]# /usr/sbin/automount --version > > Linux automount version 5.0.3 > > Directories: > config dir: /etc/sysconfig > maps dir: /etc > modules dir: /usr/lib/autofs > > Compile options: > > > [EMAIL PROTECTED] root]# uname -a > Linux l-xterm-13 2.6.24 #2 SMP PREEMPT Wed Feb 6 13:33:24 PST > 2008 i686 > i686 i386 GNU/Linux > [EMAIL PROTECTED] root]# > > Active options in /etc/sysconfig/autofs are: > DEFAULT_TIMEOUT=600 > DEFAULT_BROWSE_MODE="no" > DEFAULT_LOGGING="debug" > > All vanilla. > > A situation occurs where indirectly automounted home > directories stop being mounted at login. > > First is seen in /var/log messages: > Jun 19 09:30:56 server1 automount[18399]: statemachine:1383: > got unexpected signal -2147417261! > ... The same message occurs once more 15 seconds later... I > don't know what may have happened to cause this, I don't > believe I have ever seen this before and this may be a red > herring; possibly due to some other hardware related issue? > > Then, trying to do 'kill -USR1 `pgrep automount` ; kill -HUP > `pgrep automount`' gives this in the messages: > > Jun 19 10:32:23 server1 automount[18399]: do_notify_state: > signal 10 Jun 19 10:32:23 server1 automount[18399]: > master.c:986: assertion > failed: ap->state == ST_READY > Jun 19 10:32:23 server1 automount[18399]: master_notify_state_change: > sig 10 switching /home from 2 to 3 > > ...in response to the USR1 signal. > > It looks like it is stuck in some sort of expire limbo. It > was quite possible that the NFS server did not respond to the > mount or unmount request from the automounter and sent the > automounter into some sort of black hole. > > In response to the HUP signal: > Jun 19 10:32:29 server1 automount[18399]: re-reading master > map auto.master Jun 19 10:32:29 server1 automount[18399]: > lookup_nss_read_master: > reading master files auto.master > Jun 19 10:32:29 server1 automount[18399]: parse_init: > parse(sun): init gathered global options: (null) Jun 19 > 10:32:29 server1 automount[18399]: lookup_read_master: > lookup(file): read entry /home > > ...but directories are still not being mounted. The > automounter seems to be running correctly, but not responding > to mount requests. > > Our only solution now is to kill -9 the automounter and > rpciod (to force any pending mount/umount requests to fail > immediately) and then restart the automounter. This works > but still truncates the pwd of any process that is accessing > an automounted directory due to the 'umount -l' at automount startup. > > Is this a known problem and will Ian's patches take care of this? TIA. > > -------------------------------------------------------------- > --------------------- > This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is > prohibited. If you are not the intended recipient, please > contact the sender by reply email and destroy all copies of > the original message. > -------------------------------------------------------------- > --------------------- > > _______________________________________________ > autofs mailing list > [email protected] > http://linux.kernel.org/mailman/listinfo/autofs > ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
