У меня здесь установлен рейд-драйв:
/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
Ничего необычного.
Кроме того, мой raid-контроллер 3ware показывает все диски как OK и не показывает никаких отчетов о каких-либо проблемах с ними.
Похоже, что никакого взлома сервера нет.
Также:
ps auxww | grep somesubdir
возвращает только процесс grep для этого каталога.
ОБНОВЛЕНИЕ №2:
Я пытался оставить команду более часа, но безрезультатно. Я не знал, что делать дальше, поэтому перезапустил сервер. Проблема больше не сохраняется, хотя для получения списка каталогов в этом подкаталоге требуется около 10 секунд. Понятия не имею, в чем проблема была раньше.
Помимо приведенных выше предложений, я также видел эту проблему, когда в указанном вами каталоге находится очень большое количество файлов, из-за чего в файловой системе заканчиваются inodes. Если это возможно, попробуйте просто выйти из команды ls, чтобы посмотреть, завершится ли она через некоторое время.
ls без флагов ничего не вернет, если каталог пуст. Вам понадобится хотя бы ls -a, если вы хотите увидеть что-нибудь в случае, если каталог пуст.
Если каталог не пуст, возможно, у вас повреждена файловая система - запустите fsck для проверки. Если с файловой системой все в порядке, а каталог не пуст, следующий вопрос - ls - возможно, ваша копия ls была заменена на очень примитивную форму руткита?
Вероятно, у ваших дисков проблемы. Вы можете попробовать это:
Terminal 1$ ls /data/somedir/somesubdir/
(hang)
Terminal 2$ ps auxww | grep somesubdir
Если статус вашего ls D, это означает, что он ждет, пока диск что-то сделает. Смотреть в dmesg для сообщений о состоянии и загляните в SMART, если вы еще не используете его, чтобы узнать, насколько исправны эти диски.
Почему find работать нормально? Потому что это не делает stat() по каждому файлу. Это означает, что с каталогом все в порядке, но один или несколько файлов находятся на поврежденном разделе диска (или на чем-то подобном).
Попробуйте выяснить, где он висит, запустив
strace ls $DIR
Может быть, есть файл с именем, который содержит последовательность байтов, блокирующих ваш терминал. Иногда можно разблокировать отправку заблокированного терминала Ctrl-Q Сочетание клавиш (Ctrl-S блокирует его).
Стараться сделать /bin/ls -N | less -S и посмотрите, нет ли в имени файла подозрительных или управляющих символов. В Less эти символы будут отображаться в виде шестнадцатеричных кодов в угловых скобках, например <BF>.
Наличие файла с символами с кодом ниже 32 (от <01> к <1F>) может быть признаком компрометации системы. Или ошибка управления памятью в какой-то программе, которая там создает файлы.