ls ничего не возвращает только в определенных каталогах
У меня здесь установлен рейд-драйв:
/data/
И некоторые каталоги, как этот:
/data/somedir/somesubdir/
когда я бегу
ls
без каких-либо флагов, терминал ничего не возвращает. Он не возвращает пустой список каталогов. Он просто переходит на следующую строку и остается пустым без подсказки. Я не могу CTRL-C из этого. Я должен закрыть этот терминал и начать все сначала.
Сначала я подумал, что это как-то связано с командой ls, но она указывает на /bin/ls, и я могу нормально просматривать другие каталоги.
Кроме того, работает этот
find /data/somedir/somesubdir
сразу находит все файлы, как и ожидалось.
ОБНОВИТЬ:
Похоже, что dmesg не выдает никаких ошибок, которые я вижу. Мой рейд на /dev/sda5, так что если я сделаю
dmesg | grep sda
я получил
sd 0:0:0:0: [sda] 1953083392 512-byte hardware sectors (999979 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 1953083392 512-byte hardware sectors (999979 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: disabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3 sda4 <<7>libata version 2.21 loaded.
sda5 >
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3 FS on sda3, internal journal
EXT3 FS on sda5, internal journal
EXT3 FS on sda2, internal journal
EXT3 FS on sda1, internal journal
Ничего необычного.
Кроме того, мой 3ware raid-контроллер показывает все диски в статусе OK и не показывает никаких сообщений о проблемах с ними.
Похоже, что нет никакого компромисса сервера.
Также:
ps auxww | grep somesubdir
возвращает только процесс grep для этого каталога.
ОБНОВЛЕНИЕ № 2:
Я пытался оставить команду более часа и безрезультатно. Я не знал, что делать дальше, поэтому я перезапустил сервер. Проблема больше не сохраняется, хотя для получения списка каталогов в этом подкаталоге требуется около 10 секунд. Я понятия не имею, в чем проблема была раньше.
5 ответов
Помимо приведенных выше предложений, я также сталкивался с этой проблемой, когда в каталоге, который вы перечисляете, находится очень большое количество файлов, что может привести к исчерпанию inode файловой системы. Если это возможно, попробуйте просто оставить команду ls, чтобы увидеть, завершится ли она через некоторое время.
Ваши диски, вероятно, в беде. Вы можете попробовать это:
Terminal 1$ ls /data/somedir/somesubdir/
(hang)
Terminal 2$ ps auxww | grep somesubdir
Если статус вашего лс Dэто означает, что он ждет, пока диск что-то сделает. Смотреть в dmesg для сообщений о состоянии, и посмотрите SMART, если вы еще не используете его, чтобы увидеть, насколько здоровы эти диски.
Почему find работать нормально? Потому что это не делает stat() на каждом файле. Это означает, что каталог в порядке, но один или несколько файлов находятся в поврежденном разделе диска (или в чем-то подобном).
ls без каких-либо флагов ничего не вернет, если каталог пуст. Вам нужен по крайней мере ls -a, если вы хотите увидеть что-то, если каталог пуст.
Если каталог не пустой, возможно, у вас поврежденная файловая система - запустите fsck для проверки. Если с файловой системой все в порядке, а каталог не пустой, то следующий вопрос - ls - возможно, ваша копия ls была заменена в очень примитивной форме руткита?
Может быть, есть файл с именем, который содержит последовательность байтов, которые блокируют ваш терминал. Иногда можно разблокировать отправку заблокированного терминала Ctrl-Q Сочетание клавиш (Ctrl-S блокирует это).
Стараться сделать /bin/ls -N | less -S и посмотрите, есть ли имя файла с подозрительными или управляющими символами. Например, меньше будет отображать эти символы в виде шестнадцатеричных кодов в угловых скобках <BF>,
Наличие файла с символами с кодом ниже 32 (из <01> в <1F>) может быть признаком системного компромисса. Или ошибка управления памятью в какой-то программе, которая создает файлы там.