You are not logged in.
Pages: 1
Recently, I've came across a weird problem. I've found out that executing ls from my terminal (tried with zsh, and bash) is too much time. Here's the output of `time ls`:
...
...
ls --color=tty 0.00s user 0.00s system 0% cpu 1:30.03 totalNow, this problem is particular to only my home directory. No other directories I've tried so far seem to have this problem. What I've found out to be more strange is that if I try redirecting the output of `ls` to a file with `ls > my_files` and then `cat my_files`, it takes the usual amount of time. Could it be that there's some file with some special character sequence that's causing the terminal to freeze up? If so, how should I go about finding the culprit?
Thanks.
Offline
Given the timing breakdown it appears to be blocking an unreasonably long time on IO. Do repeated back-to-back executions reduce the time delay (listing gets cached in RAM)? And is your home directory on a separate disk/partition from the rest of your system? If so, then you should investigate the integrity of the disk using a tool like SMART, or running a file system check.
Also, does the problem persist when using `ls --color=none`? What if you list your home directory as the root user (who is presumably using a simpler profile)? Finally, if you are using a fancy terminal, do you observe the same behavior in xterm or the framebuffer?
Offline
Defragment the filesystem, perhaps?
e4defrag ~/Jin, Jîyan, Azadî
Offline
The filesystem theory collides with the suggestion that subsequent calls are affected, but redirected ones are not.
My money would be on the terminal indicator, the mount of files, coloring and layout (also try "ls -f1")
Online
Given the timing breakdown it appears to be blocking an unreasonably long time on IO. Do repeated back-to-back executions reduce the time delay (listing gets cached in RAM)? And is your home directory on a separate disk/partition from the rest of your system? If so, then you should investigate the integrity of the disk using a tool like SMART, or running a file system check.
Also, does the problem persist when using `ls --color=none`? What if you list your home directory as the root user (who is presumably using a simpler profile)? Finally, if you are using a fancy terminal, do you observe the same behavior in xterm or the framebuffer?
I don't think the issue is filesystem related as `ls --color=none` is taking the usual amount of time to complete. And by the way, I'm using xterm. Maybe it's something to do with the color profile? I'll try changing it out. Thanks for your reaply.
Offline
Defragment the filesystem, perhaps?
e4defrag ~/
Thanks Head_on_a_Stick, but it does not seem to be a fragmentation related issue as trying ls explicitly without colors and formatting seems to resolve the issue.
Offline
Briefly ensure that it's not the TE (try eg. urxvt) and then strace the call to see whether it stalls for a specific file.
Online
Pages: 1