Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a very strange problem, one that may be too difficult to diagnosis without machine access, but maybe someone here may be able to help.

I am using OS X, and on my local machine ls executes instantly. However, when I log into one particular remote server, and execute ls in the home directory only, it takes about 15 seconds to return. And there's only a few files in the home directory. If I switch to a sub-directory, or a higher directory, ls executes immediately.

Now here's the weird thing: if I use a different computer to access the remote server and run ls on the home directory, it returns immediately.

In summary: my particular laptop + one particular remote server + one particular directory = slow ls execution

Any ideas? Or at least a way to go about debugging this?

EDIT: Okay, more weirdness. It's only slow on the first execution of ls. All subsequent executions are fast. I guess I never bothered to type it again after it was so slow the first time.

share|improve this question
Is it just 'ls' or 'ls -l' that is slow? 'ls -l' needs to stat every file in addition to looking at /etc/passwd (or worse, consult an external user database, where this db is centralized). In any case, you may run strace on ls and see where the 15 sec pause occurs. This should lead you to the answer. – arielf Mar 3 '13 at 9:35
Try ls-ing another directory just after logging in, maybe it's the first ls that's problematic - not the home directory. – gronostaj Mar 3 '13 at 9:35
@arielf It's just ls. – Nick Mar 3 '13 at 9:54

It is a bit difficult to be sure what's going on. Your symptoms could be easily explained by a mixture of a real issue (well, not-so-issue) and testing bias.

For example, let's suppose the Linux server is simply idling its disk and the directory you want is not in cache (or maybe it's mounted or linked to a device that is spinned down, as an external disk).

Then the first access requires spin-up/deidling, and there the 15 seconds go.

You go in another directory, and it's fast, because it's either on another device or on the now-spinning device.

You go back to the same directory and now it's fast (the IOSS cache might also have something to do with it).

You logout and login from elsewhere, but now the device is still spinning, the cache still primed, and the directory is fast.

To be sure that it's not a problem like this, you would need to wait a suitable time and retry logging in first thing from the third computer - the one where ls was fast - and check out whether now the ls is actually slow.

share|improve this answer
You make a good point. I'll give that a try. – Nick Mar 3 '13 at 10:19

Answering the part on how to go about debugging this. Try this in the Linux session:

sudo strace ls

And pay attention to the system call that hangs for ~15 sec.

(On OS-X one could use 'dtruss', or use dtrace (man dtrace))

share|improve this answer
Sorry, I should've clarified. I am ssh-ing to a Linux server from OS X. – Nick Mar 3 '13 at 9:55
thanks. I'll edit my answer to take this into account. – arielf Mar 3 '13 at 10:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .