[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Switch-off problem

Le lundi 21 juillet 2008, Bob McGowan a écrit :
> Jan Willem Stumpel wrote:
> > Ron Johnson wrote:
> >> On 07/19/08 04:46, Jan Willem Stumpel wrote:[..]
> >>
> >>> Now my theory is that the switch-off problem occurs after the
> >>>  following events:
> >>>
> >>> 1 - I mount the remote usb drive.
> >>> 2 - my wife switches off her computer.
> >>> 3 - I try to umount the remote usb drive -- this cannot be
> >>>     done.
> >>>
> >>> I suppose the shutdown program also tries to umount nfs
> >>> mounts, but fails, and then instead of skipping this step,
> >>> just hangs. Does this make sense? If so, is there a way to
> >>> solve this problem?
> >>
> >> Manually "umount -l" the remote drive before you shutdown?
> >
> > This does not work. Manually umounting the nfs drive (after the
> > computer which hosts the nfs drive is switched off) just leads to
> > a hang, whether the "lazy" switch is applied or not. In fact I
> > cannot even type the umount command entirely: the system hangs
> > immediately after typing the first 3 characters (including the
> > leading /) of the mount point.
> This hanging at "cannot even type the umount command entirely: the
> system hangs immediately after typing the first 3 characters" sounds
> very strange.
> The NFS subsystem can't know that a umount has been entered until the
> shell takes the full command line, forks a copy of itself and then
> execs the new command.  At least, that's how I understand things. ;)

It could be a tab completion. Personaly I always use tab completion for 
umount. I don't know exactly what is done in the tab completion of 
umount. If it is just mtab which is read then it's strange, if some 
kind of ls in the directory is done then it is perfectly normal.

> I'd suggest focusing on this, though I have no good suggestions for
> debugging it.  The only thing I can think of is to run a subshell
> under strace, to a file, and try the umount in the subshell.  Perhaps
> there'll be something there to indicate what's going on.

You also can use the NFS client in gdb and sniff the network when the 
NFS server goes down (to see if a broadcast is done to all client).

> I've never worked with strace and an interactive program like a
> shell, so you may not get much from the above.  You could force
> non-interactive operation by using the shell '-c' argument:
>     strace -o nfs_hang.trace -f bash -c 'umount /...' &
> By backgrounding the program, you should get a prompt from which you
> can issue a 'kill' to the 'bash' process.  If you can kill it, then
> strace should print to and close the trace file "normally".
> <<deleted NFS comments>>
> > Regards, Jan

Thomas Preud'homme

Why Debian : http://www.debian.org/intro/why_debian

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: