I don't know how to debug this situation:1) I try to execute:ls /home/user2) 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/user4) 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!
ls behaves differently under strace
networking;sshfs;strace
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