/ diretório tmp: 0 arquivos, mas mostra completo?

Question

Relacionado a outra postagem em que finalmente consegui excluir arquivos em / tmp graças a outro pôster.

No entanto, no final, o administrador do sistema teve que restaurar um instantâneo de alguns dias atrás para recuperar o serviço mysql.

Eu deduzi que o servidor mysql não estava rodando, e não estava. Um erro foi que não foi possível gravar no diretório tmp para criar os arquivos mysqld.sock / .pid para que eles não existissem.

Assim, o servidor foi reiniciado / reinicializado e finalmente restaurado a partir de um instantâneo anterior, então tudo está funcionando, mas o instantâneo era de alguns dias atrás, então os sinais do tell-tell estão nesta saída:

drwxrwxrwt  2 root  root  34471936 Oct  8 20:47 tmp

Esse grande número ainda está sendo "lembrado" de alguma forma e estou tentando descobrir o que está escrevendo para essa pasta? No Drupal, o caminho para os arquivos de pré-visualização é definido para esse diretório, mas eu fiz uma série de testes (o site não tem contas de login / apenas para download de dados), visualizando etc e o número do arquivo nunca foi alterado na pasta / tmp está escrevendo para essa pasta?

Este é um servidor web que não é desligado / reinicializado a menos que haja algum problema. Mesmo assim, o diretório / tmp não é esvaziado na reinicialização. Além disso, no arquivo rsC, o TMPTIME=0 ainda está no padrão.

Então, não tenho certeza de mais onde procurar ou como investigar o que está mantendo esse 3441936 size quando o diretório real está vazio? Ou como pesquisar quais processos estão usando esse diretório.

Isso é apenas para uma instalação do Drupal. Ubuntu 12.

    

Answer 1

Tente isso.

$ sudo lsof | egrep '^COMMAND|deleted'

Exemplo de saída que vejo no meu sistema ...

COMMAND     PID        USER   FD      TYPE             DEVICE   SIZE/OFF       NODE NAME
mysqld     2842      mysql    5u      REG                9,1        4633    6209543 /tmp/ibLRNV1i (deleted)
mysqld     2842      mysql    6u      REG                9,1         424    6209545 /tmp/ibnnYl1y (deleted)
mysqld     2842      mysql    7u      REG                9,1           0    6209546 /tmp/ib5ViM0O (deleted)
mysqld     2842      mysql    8u      REG                9,1           0    6209547 /tmp/ibh9U55F (deleted)
mysqld     2842      mysql   13u      REG                9,1           0    6209548 /tmp/ibRzqtwm (deleted)
mysqld     2842      mysql  319u      REG                9,1    25894907    6209553 /tmp/MLFxqPDX (deleted)
mysqld     2842      mysql  350u      REG                9,1   267677827    6209550 /tmp/MLFBkHbP (deleted)

Uma característica comum de muitos sistemas de arquivos * nix é o fato de que nada impede que um processo continue a ler / gravar em / de um arquivo excluído, e não há nada que impeça a exclusão de um arquivo que um processo ainda tenha aberto. / p>

Uma maneira de alguns programas garantirem que os arquivos temporários não permaneçam (e possivelmente também como uma medida de segurança, embora não tenha certeza de como isso é seguro) é abri-los e imediatamente "desvincular" (excluir) eles. Se o processo terminar inesperadamente, o espaço em disco será liberado. O MySQL faz isso:

  

O MySQL organiza que os arquivos temporários sejam removidos se o mysqld for finalizado. Em plataformas que o suportam (como o Unix), isso é feito ao desvincular o arquivo depois de abri-lo. A desvantagem disso é que o nome não aparece nas listagens de diretórios e você não vê um grande arquivo temporário que preenche o sistema de arquivos no qual o diretório de arquivos temporários está localizado. (Nesses casos, lsof + L1 pode ser útil na identificação de arquivos grandes associados ao mysqld.)

     

^{- link}

Ponto importante: Quando um arquivo que ainda está aberto é excluído, o espaço não é realmente liberado no disco até que o último processo que contém um identificador no arquivo o feche. Até que o arquivo seja fechado, ninguém, incluindo o root, poderá liberar esse espaço além de matar o processo. Por outro lado, matando (ou parando graciosamente, se possível) o processo deve sempre liberar o espaço.

Então, eu recomendo que você dê uma olhada no que seu sistema pode ter na forma de arquivos abertos e excluídos, e isso pode lhe dar algo para continuar.

No caso do meu sistema, o MySQL tem vários arquivos temporários abertos, alguns deles bastante grandes.

Se você quiser espiar dentro desses arquivos, isso é feito facilmente, embora a natureza do que você possa discernir varie muito. Pegue o PID e os dígitos em FD que fazem isso ... exemplo, PID 2842 FD 350:

$ sudo strings /proc/2842/fd/350 | less

Se o MySQL tiver arquivos temporários excluídos abertos, parando e reiniciando o MySQL irá liberar esse espaço, e então você precisará investigar o que pode estar mantendo abertos, pois eles demoram mais tempo do que o apropriado e se você tem consultas que são gerando tabelas temporárias excessivamente grandes e esgotando seu espaço / tmp. Se o seu diretório / tmp for sua própria partição / sistema de arquivos, então df -h lhe dará uma resposta melhor sobre o espaço livre e usado. Você provavelmente não precisa se preocupar muito com o tamanho real da própria entrada de diretório.

E é claro que pode não ser o MySQL. :)

    

Answer 2

ext [234] não diminui o tamanho dos diretórios quando você apaga arquivos; apenas marca as entradas como excluídas para que possam ser reutilizadas posteriormente. Se você realmente quiser recuperar esses 34 MB, precisará excluir e recriar o diretório ou inicializar no modo de recuperação e executar e2fsck -D no volume.