Não é possível remover ou listar o diretório (ls ou rm) Linux - Debian

2

Eu tenho um diretório de arquivos de log em / var / log / apache2 / vhosts em um servidor Debian dedicado. Todos os dias eu divido o principal access_log nos respectivos arquivos vhostname.com_access_log em / var / log / apache2 / vhosts

Na última semana, notei que o servidor parou de responder e, toda vez que isso acontece, parece haver várias instâncias de rotação de log sendo executadas.

Após alguma investigação, decidi verificar o conteúdo de / var / log / apache2 / vhosts para ver se havia algum tipo de problema. Eu posso 'cd' no diretório, mas não consigo listar seu conteúdo. O comando 'ls' não morre, simplesmente não faz nada.

Depois de tentar várias maneiras diferentes de listar o conteúdo do arquivo, decidi apenas excluí-lo e criar um novo arquivo. A execução de rm no diretório a partir do diretório pai não pareceu funcionar no entanto: rm -rf vhosts. Do ponto de vista de 'top' eu posso ver que 'rm' está rodando e usando uma pequena quantidade de cpu ... Ele já está funcionando há cerca de uma hora.

Alguma idéia do que está acontecendo e como posso me livrar desse diretório?

MAIS INFORMAÇÕES:

Ver muito deste tipo de erro em / var / log / messages não sabe se está relacionado:

    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]  =======================

E mais alguns erros:

    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]  =======================
    
por user568829 17.10.2011 / 10:10

4 respostas

2

Parece-me que você pode ter um número enorme de arquivos no diretório. Eu vi sintomas muito semelhantes ao que você descreve com diretórios muito grandes.

Pode ter havido algum tipo de problema (possivelmente um problema de configuração com o logrotate) em que você acabou com milhões de arquivos. Quando você chega aos milhões, a maioria dos sistemas de arquivos começa a ter problemas. Apenas fazendo um ls pode levar uma quantidade enorme de tempo, e pode até morrer se você esperar o tempo suficiente. Comandos como rm também terão problemas devido ao grande número de arquivos. Da mesma forma, coisas como logrotate parecerão travar porque executar operações simples no diretório levará muito tempo para ser concluído.

Uma maneira de verificar isso é fazer um ls -l no diretório acima (/ var / log / apache2 / neste caso) e visualizar o tamanho da entrada de diretório (não o conteúdo). Por exemplo (de um servidor que tenho, onde existem alguns diretórios com muitos arquivos):

$ 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

Observe o tamanho da entrada de diretório em comparação com o número de arquivos nela.

Sua melhor aposta é tentar visualizar os arquivos com algo como find . Ele não tenta extrair toda a lista antes de exibi-las e pode permitir que você consulte e opere em um diretório sem os problemas que você vê em ls e rm . Alguns exemplos úteis estão abaixo.

Número de arquivos:

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

Veja uma amostra de arquivos no diretório:

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

Remova todos os arquivos correspondentes a um padrão do diretório:

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

Nota : Acabei de notar o seu comentário, em que mostrou um ls de um único diretório:

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

Isso confirma minhas suspeitas. 126406656 bytes é 120MB. Essa é uma entrada de diretório muito grande (do meu exemplo acima, eu tinha uma entrada de diretório de 11MB com 200k arquivos) e sugere que você tinha milhões de arquivos nesse diretório.

    
por 21.04.2014 / 21:50
0

Isso deve estar em Falha do servidor , mas:

o bit de leitura em seu diretório parece desativado: use algo como chmod a+r nome_do_diretório para corrigi-lo.

É mais provável que isso aconteça quando o diretório é criado; o script de rotação de log faz isso? É totalmente esperado que várias instâncias simultâneas desse script causem problemas, mas estou surpreso que isso possa criar problemas de permissão no diretório. Em qualquer caso, você precisa de uma maneira mais rápida de girar e, possivelmente, de um mecanismo para impedir que o script inicie quando já estiver em execução.

    
por 17.10.2011 / 10:19
0

As tarefas suspensas são um erro muito grave. É tão grave que existe um arquivo proc chamado / proc / sys / kernel / hung_task_panic para automaticamente entrar em pânico / reinicializar. Isso significa que um processo ficou pendurado no kernel por um longo tempo, isso não deveria acontecer sob o uso normal.

  • Verifique seu uso / troca de memória
  • Verifique seu sistema de arquivos / disco
por 17.10.2011 / 12:51
0

O problema parece ter se resolvido ??!?

Eu notei que a carga no servidor tinha caído de sua média de pico de cerca de 70 para cerca de 1-3 (onde normalmente fica).

Eu corri: screen rm -rf vhosts

Voltei cerca de meia hora depois e tentei retomar a tela e nada. Yay! O diretório foi deletado.

Realmente, ninguém sabe o que aconteceu / está acontecendo, mas pelo menos parte do problema desapareceu.

Não há mais erros de kernel estranhos.

    
por 17.10.2011 / 21:20