Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I don't know how to debug this situation:

1) I try to execute:

ls /home/user

2) ls blocks and does not print anything. I assume it is because /home/user contains /home/user/sshfs_files, which is an sshfs-mounted directory, but the network went down on my machine (the network is up again but I guess the SSH connection has been lost).

3) As i wanted to be sure that the sshfs-mounted directory was the cause of this hang up, i tried the same command under strace:

strace -o /tmp/log ls /home/user

4) And the ls actually worked ! So now the situation is that ls works under strace but blocks on its own.

How is it even possible? How to explain this situation? How can I see where ls block if it doesn't block under strace?

Thanks!

share|improve this question
    
How about ls /home/user | cat? This might simply be ls detecting how it's output is treated... –  rozcietrzewiacz Apr 20 '12 at 15:53
2  
Note that it would make sense, since the output of ls is (on typical setups) coloured. Colouring is desired only when the output is not redirected, because otherwise the escape sequences would mess up the output. And in order to make the output colourful, ls must determine the type of each entry. At this point it hangs with your sshs_files dir. –  rozcietrzewiacz Apr 20 '12 at 15:59
1  
@rozcietrzewiacz: You should make your comment an answer, so user5528 can accept it. Unaccepted question give you a bad carma. –  user unknown Apr 20 '12 at 16:04
1  
Since @rozcietrzewiacz's comment was correct, that makes this a near exact duplicate of this question. At least the accepted answer there applies here. –  jw013 Apr 20 '12 at 16:50
1  
@jw013 True. Near, but not exact: the title can make a difference to other people experiencing similar problems. So... This one might get closed eventually, but since prompted, I'll post an answer. –  rozcietrzewiacz Apr 20 '12 at 17:13

2 Answers 2

up vote 3 down vote accepted

As jw13 pointed out, this is almost an exact duplicate of "ls taking long time in small directory" - at least as far as the explanation is concerned. Make sure to read the comments there too!

In a nutshell, some popular command-line programs like ls can operate differently when their output does not go directly to a terminal. In this very case, ls, which is probably aliased to ls --color=auto, tries to detect the type of each directory entry for colouring purposes. At his point it hangs, unable to perform a stat operation on your sshfs-mounted directory.

Adding to MadScientist's answer to the mentioned question: If you are curious of how strace or gdb can help in debugging ls' behaviour, I suggest you run something like

 strace -o /tmp/log ls --color=always /home/user
share|improve this answer

Well, that is common behaviour for programs under debug, and not really avoidable. The initialization of variables changes, there are more informations available, the program flow is changed.

Either you get the source of ls, and run it through a different debugger, hoping it will show the error, or you try to find an answer, a workaround on other ways.

share|improve this answer
    
I tried with gdb and ls didn't block either –  user368507 Apr 20 '12 at 15:48
    
@user5528: So maybe you need to experiment: What happens if the ssh-connection isn't lost? Can you filter the sshfs-dir with ls [^s]* for example? What does find ~ maxdepth -1 -ls yield? –  user unknown Apr 20 '12 at 16:00
    
problem solved in the comments to the original post. thanks –  user368507 Apr 20 '12 at 16:03
    
A debugger does not change the initialization of variables. It can subtly change the timing of execution as it slows down certain parts of the program, and this can alter the behavior of race conditions and other particularly insidious bugs, but does not change initialization. –  psusi Apr 20 '12 at 22:51
1  
A debugger can definitely change initialization when the variables are not initialized in code. They are nicely initialized to 0 running in a debugger and initialized to whatever is in memory in release mode. –  Étienne May 15 '13 at 7:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.