Назад | Перейти на главную страницу

Невозможно удалить или отобразить каталог (ls или rm) Linux - Debian

У меня есть каталог файлов журнала в / var / log / apache2 / vhosts на выделенном сервере Debian. Каждый день я разбиваю основной журнал доступа на соответствующие файлы vhostname.com_access_log в / var / log / apache2 / vhosts

Примерно за последнюю неделю я заметил, что сервер перестал отвечать, и каждый раз, когда это происходит, кажется, что выполняется несколько экземпляров ротации журналов.

После некоторого расследования я решил проверить содержимое / var / log / apache2 / vhosts, чтобы увидеть, есть ли какие-то проблемы. Я могу войти в каталог через cd, но не могу перечислить его содержимое. Команда ls не умирает, она просто ничего не делает.

Попробовав различные способы составить список содержимого файла, я решил просто удалить его и создать новый файл. Однако запуск rm в каталоге из родительского каталога тоже не сработал: rm -rf vhosts. С точки зрения «сверху» я вижу, что «rm» работает и использует небольшое количество процессора ... Теперь он работает около часа.

Есть идеи, что происходит и как я могу избавиться от этого каталога?

ДАЛЬНЕЙШАЯ ИНФОРМАЦИЯ:

Видя много ошибок этого типа в / var / log / messages, не знаю, связана ли это:

    Oct 15 12:22:39 sp5059b kernel: [2257339.255530] apache2       D a9b86504     0 32217   9125
    Oct 15 12:22:39 sp5059b kernel: [2257339.255533]        dea15620 00000086 00000000 a9b86504 0007f05b dea157ac c1fdbfc0 00000001 
    Oct 15 12:22:39 sp5059b kernel: [2257339.255538]        00000000 00000000 00000001 00000000 00000000 00000000 00000000 00000000 
    Oct 15 12:22:39 sp5059b kernel: [2257339.255542]        f7246ec0 f7246ec8 f7246ec4 dea15620 c02b95c6 c2483e80 d7085e80 dea15620 
    Oct 15 12:22:39 sp5059b kernel: [2257339.255547] Call Trace:
    Oct 15 12:22:39 sp5059b kernel: [2257339.255553]  [<c02b95c6>] __mutex_lock_slowpath+0x50/0x7b
    Oct 15 12:22:39 sp5059b kernel: [2257339.255557]  [<c02b945c>] mutex_lock+0xa/0xb
    Oct 15 12:22:39 sp5059b kernel: [2257339.255561]  [<c015810c>] generic_file_aio_write+0x41/0xa9
    Oct 15 12:22:39 sp5059b kernel: [2257339.255565]  [<f892ef99>] ext3_file_write+0x19/0x83 [ext3]
    Oct 15 12:22:39 sp5059b kernel: [2257339.255575]  [<c017460e>] do_sync_write+0xbf/0x100
    Oct 15 12:22:39 sp5059b kernel: [2257339.255581]  [<c0131a98>] autoremove_wake_function+0x0/0x2d
    Oct 15 12:22:39 sp5059b kernel: [2257339.255585]  [<c0132368>] set_process_cpu_timer+0x27/0xae
    Oct 15 12:22:39 sp5059b kernel: [2257339.255590]  [<c0125be2>] do_setitimer+0x2aa/0x31a
    Oct 15 12:22:39 sp5059b kernel: [2257339.255594]  [<c017e0a0>] fasync_helper+0x3c/0xb7
    Oct 15 12:22:39 sp5059b kernel: [2257339.255597]  [<c01bafe5>] security_file_permission+0xc/0xd
    Oct 15 12:22:39 sp5059b kernel: [2257339.255601]  [<c017454f>] do_sync_write+0x0/0x100
    Oct 15 12:22:39 sp5059b kernel: [2257339.255605]  [<c0174d80>] vfs_write+0x83/0x120
    Oct 15 12:22:39 sp5059b kernel: [2257339.255608]  [<c0175352>] sys_write+0x3c/0x63
    Oct 15 12:22:39 sp5059b kernel: [2257339.255612]  [<c01038d2>] syscall_call+0x7/0xb
    Oct 15 12:22:39 sp5059b kernel: [2257339.255618]  =======================

И еще несколько ошибок:

    Oct 15 12:22:39 sp5059b kernel: [2257339.255618]  =======================
    Oct 15 13:52:55 sp5059b kernel: [2262820.703285] INFO: task kswapd0:173 blocked for more than 120 seconds.
    Oct 15 13:52:55 sp5059b kernel: [2262820.703310] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Oct 15 13:52:55 sp5059b kernel: [2262820.703342] kswapd0       D 9527f7ea     0   173      2
    Oct 15 13:52:55 sp5059b kernel: [2262820.703346]        f747c4e0 00000046 c036f160 9527f7ea 0007f529 f747c66c c1fdbfc0 00000001 
    Oct 15 13:52:55 sp5059b kernel: [2262820.703352]        00000000 00000001 0051b47e 00000000 00000000 00000000 00000246 c0131ba7 
    Oct 15 13:52:55 sp5059b kernel: [2262820.703357]        f77dc400 f7731dc4 f77dc450 00396fe5 f8899e28 f77dc414 00000000 f747c4e0 
    Oct 15 13:52:55 sp5059b kernel: [2262820.703362] Call Trace:
    Oct 15 13:52:55 sp5059b kernel: [2262820.703374]  [<c0131ba7>] prepare_to_wait+0x12/0x4d
    Oct 15 13:52:55 sp5059b kernel: [2262820.703383]  [<f8899e28>] log_wait_commit+0x8b/0xd1 [jbd]
    Oct 15 13:52:55 sp5059b kernel: [2262820.703393]  [<c0131a98>] autoremove_wake_function+0x0/0x2d
    Oct 15 13:52:55 sp5059b kernel: [2262820.703398]  [<f88975dd>] journal_try_to_free_buffers+0x123/0x13b [jbd]
    Oct 15 13:52:55 sp5059b kernel: [2262820.703407]  [<f89320f7>] ext3_releasepage+0x0/0x57 [ext3]
    Oct 15 13:52:55 sp5059b kernel: [2262820.703420]  [<c0156409>] try_to_release_page+0x33/0x45
    Oct 15 13:52:55 sp5059b kernel: [2262820.703424]  [<c015ee80>] shrink_page_list+0x3c7/0x4a8
    Oct 15 13:52:55 sp5059b kernel: [2262820.703431]  [<c015e349>] isolate_lru_pages+0x44/0x17f
    Oct 15 13:52:55 sp5059b kernel: [2262820.703436]  [<c015e349>] isolate_lru_pages+0x44/0x17f
    Oct 15 13:52:55 sp5059b kernel: [2262820.703441]  [<c015f04f>] shrink_inactive_list+0xee/0x2fd
    Oct 15 13:52:55 sp5059b kernel: [2262820.703450]  [<c015f30e>] shrink_zone+0xb0/0xcd
    Oct 15 13:52:55 sp5059b kernel: [2262820.703454]  [<c015fa64>] kswapd+0x27b/0x3ed
    Oct 15 13:52:55 sp5059b kernel: [2262820.703459]  [<c015e484>] isolate_pages_global+0x0/0x42
    Oct 15 13:52:55 sp5059b kernel: [2262820.703463]  [<c0131a98>] autoremove_wake_function+0x0/0x2d
    Oct 15 13:52:55 sp5059b kernel: [2262820.703468]  [<c015f7e9>] kswapd+0x0/0x3ed
    Oct 15 13:52:55 sp5059b kernel: [2262820.703471]  [<c01319d7>] kthread+0x38/0x5d
    Oct 15 13:52:55 sp5059b kernel: [2262820.703474]  [<c013199f>] kthread+0x0/0x5d
    Oct 15 13:52:55 sp5059b kernel: [2262820.703477]  [<c01044f7>] kernel_thread_helper+0x7/0x10
    Oct 15 13:52:55 sp5059b kernel: [2262820.703482]  =======================
    Oct 17 16:39:21 sp5059b kernel: [2448749.835890] INFO: task exim4:15225 blocked for more than 120 seconds.
    Oct 17 16:39:21 sp5059b kernel: [2448749.835915] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    Oct 17 16:39:21 sp5059b kernel: [2448749.835947] exim4         D 0f35bdb1     0 15225  15223
    Oct 17 16:39:21 sp5059b kernel: [2448749.835951]        c24032c0 00000082 c1fdbfc0 0f35bdb1 00089b8e c240344c c1fdbfc0 00000001 
    Oct 17 16:39:21 sp5059b kernel: [2448749.835956]        00000000 00000001 000013fa 00000000 00000000 00000000 00000246 c0131ba7 
    Oct 17 16:39:21 sp5059b kernel: [2448749.835962]        f77dc400 e6185f20 f77dc450 0039e41c f8899e28 f77dc414 00000000 c24032c0 
    Oct 17 16:39:21 sp5059b kernel: [2448749.835967] Call Trace:
    Oct 17 16:39:21 sp5059b kernel: [2448749.835978]  [<c0131ba7>] prepare_to_wait+0x12/0x4d
    Oct 17 16:39:21 sp5059b kernel: [2448749.835986]  [<f8899e28>] log_wait_commit+0x8b/0xd1 [jbd]
    Oct 17 16:39:21 sp5059b kernel: [2448749.835996]  [<c0131a98>] autoremove_wake_function+0x0/0x2d
    Oct 17 16:39:21 sp5059b kernel: [2448749.836001]  [<f8896451>] journal_stop+0x12f/0x151 [jbd]
    Oct 17 16:39:21 sp5059b kernel: [2448749.836009]  [<f892f0b7>] ext3_sync_file+0x57/0x9c [ext3]
    Oct 17 16:39:21 sp5059b kernel: [2448749.836022]  [<c015744c>] filemap_fdatawrite+0x12/0x16
    Oct 17 16:39:21 sp5059b kernel: [2448749.836027]  [<c018f5b5>] do_fsync+0x41/0x83
    Oct 17 16:39:21 sp5059b kernel: [2448749.836031]  [<c018f614>] __do_fsync+0x1d/0x2b
    Oct 17 16:39:21 sp5059b kernel: [2448749.836034]  [<c01038d2>] syscall_call+0x7/0xb
    Oct 17 16:39:21 sp5059b kernel: [2448749.836041]  =======================

Мне кажется, у вас могло быть огромное количество файлов в каталоге. Я видел симптомы, очень похожие на те, которые вы описываете для очень больших каталогов.

Возможно, возникла какая-то проблема (возможно, проблема конфигурации с logrotate), из-за которой у вас остались миллионы файлов. Как только вы попадете в миллионы, у большинства файловых систем начнутся проблемы. Просто делаю ls может занять очень много времени и даже умереть, если вы будете ждать достаточно долго. Команды вроде rm точно так же будут проблемы из-за огромного количества файлов. Точно так же такие вещи, как logrotate, будут зависать, потому что выполнение простых операций с каталогом займет очень много времени.

Один из способов проверить это - выполнить ls -l в каталоге выше (в данном случае / var / log / apache2 /) и просмотрите размер записи в каталоге (а не ее содержимое). Например (с моего сервера, где есть несколько каталогов с множеством файлов):

$ ls -lh
rwxrwxr-x 2 ironport ironport  11M Apr 21 19:37 oma01syslog01/
drwxrwxr-x 2 ironport ironport  12M Apr 21 19:37 oma01syslog02/
drwxrwxr-x 2 ironport ironport 5.8M Mar 17 12:30 sat01syslog01/
drwxrwxr-x 2 ironport ironport 4.0K Jun 29  2011 swn01syslog01/

$ for DIR in * ; do echo -n "$DIR:  " ; find $DIR -type f -print | wc -l ; done
oma01syslog01:  204332
oma01syslog02:  195500
sat01syslog01:  70960
swn01syslog01:  0

Обратите внимание на размер записи каталога по сравнению с количеством файлов в нем.

Лучше всего попробовать просмотреть файлы с чем-то вроде find. Он не пытается вытащить весь список перед их отображением и может позволить вам запрашивать и работать с каталогом без проблем, которые вы видите в ls и rm. Ниже приведены некоторые полезные примеры.

Количество файлов:

find ./directory/name/here -type f -print | wc -l

Просмотрите образец файлов в каталоге:

find ./directory/name/here -type f -print | head -20 | xargs ls -lh

Удалите из каталога все файлы, соответствующие шаблону:

find ./directory/name/here -type f -iname '*.log' -print | xargs rm -rf

Заметка: Я только что заметил ваш комментарий, где вы показали ls из одного каталога вверх:

drwxr-xr-x 2 root root 126406656 2011-10-17 18:51 vhosts

Это подтверждает мои подозрения. 126406656 байт - 120 МБ. Это довольно большая запись в каталоге (из приведенного выше примера у меня была запись в каталоге размером 11 МБ с 200 тыс. Файлов), и это предполагает, что в этом каталоге были миллионы файлов.

Проблема вроде решилась сама собой ??!?

Я заметил, что нагрузка на сервер снизилась с пикового среднего значения около 70 до уровня 1-3 (где он обычно находится).

Я запустил: screen rm -rf vhosts

Вернулся примерно через полчаса и попытался возобновить экран и ничего. Ура! Каталог был удален.

На самом деле никто не знает, что произошло / происходит, но, по крайней мере, часть проблемы исчезла.

Больше никаких странных ошибок ядра.

Зависание задач - очень серьезная ошибка. Это настолько серьезно, что есть файл proc с именем / proc / sys / kernel / hung_task_panic для автоматической паники / перезагрузки. Это означает, что процесс зависает в ядре очень долго, этого не должно происходить при нормальном использовании.

Проверьте использование памяти / свопинг
Проверьте вашу файловую систему / диск

Это должно быть на Ошибка сервера, но:

бит чтения в вашем каталоге кажется отключенным: используйте что-то вроде chmod a+rимя директора чтобы исправить это.

Скорее всего, это произойдет при создании каталога; это делает сценарий ротации журналов? Ожидается, что несколько одновременных экземпляров этого сценария вызовут проблемы, но я удивлен, что это вызовет проблемы с разрешениями в каталоге. В любом случае вам нужен более быстрый способ поворота и, возможно, механизм, предотвращающий запуск сценария, когда он уже запущен.