busybox binaries hangs when trying to do "lstat"

[Denys Vlasenko]

On Friday 06 June 2008 19:36, Ralf Friedl wrote:
> Sid Kapoor wrote:
> > The busybox 'ls' applet uses the kernel(system) calls such as lstat to
> > locate mounted file system information. When a file system has been
> > mounted from an NFS server and that server is temporarily unavailable,
> > the calls 'lstat' uses may block in the kernel, resulting in the whole
> > terminal in a hung-up status.
> >
> > I NFS mounted a folder at the mount point '/root/tmp/'. When the
> > server was unavailable, and 'ls' was executed at /root, it tried to
> > locate mounted file system's information. Eventually the system did
> > not respond to the 'lstat' call and the system hanged. The final lines
> > of the log of the strace command while executing 'ls' is as follows
> > (full log file is attached with this mail) :
> >
> >
> > lstat64("./tmp", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > --- SIGHUP (Hangup) @ 0 (0) ---
> > +++ killed by SIGHUP +++
> >
> > Can anyone tell the reason why is this happening? Is it a bug in
> > busybox? Waiting for reply.
> >   
> The last line from strace shows that lstat succeeds.
> You may consider the NFS option 'soft' for your mount.
> 
> The reason why busybox ls uses lstat is that is uses colored display of 
> names by default, even with no options or environment variables set.

Well, I don't understand what the original post implies. What ls
should do instead? It has to obtain filename list SOMEHOW, no?
It can be done only by asking the kernel to do readdir, [l]stat,
etc. And if that call takes very long (as in: 5 years) to finish
due to NFS server, it's not ls' fault.

This is how NFS operated for as long as I remember. This is actually
a design choice - if you use "hard" NFS mounts and NFS server dies,
file accesses will hang (as opposed to "fail") in the hope that
server will eventually come back online. (And they DO succeed if it
comes back online).
--
vda