df -l está mostrando 100% cheio, mas o arquivo foi removido

Question

Recebi um alerta de que um disco local estava cheio;

dm@fooserv:/local/data/plog $ df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/rootvg-datavol
                     121790564 115659468         0 100% /local/data
tmpfs                   102400      1028    101372   2% /var/asagent/lib/asagen

Eu verifiquei o diretório e vi o arquivo.

user@fooserv:/local/data/plog $ ls -ltr
total 84926904
lrwxrwxrwx 1 user ers_gsd          37 Aug 15 03:00 bomb.log -> /local/data/plog/bomb.31655.log
-rw-rw-rw- 1 user ers_gsd           0 Aug 15 03:00 recovery.log
drwxrwxrwt 2 user ers_gsd        4096 Aug 15 03:00 log/
-rw-rw-rw- 1 user ers_gsd           0 Aug 15 03:00 dropping.log
-rw-rw-rw- 1 user ers_gsd       10109 Aug 15 09:20 proc_fooserv.log
-rw-rw-rw- 1 user ers_gsd      381083 Aug 15 10:25 trip_bomb.rip.1.log
-rw-rw-rw- 1 user ers_gsd    60563456 Aug 15 13:35 bomb.31655.log
-rw-rw-rw- 1 user ers_gsd           0 Aug 15 13:37 bomb.stats
-rw-rw-rw- 1 user ers_gsd 86819237888 Aug 15 13:37 process-one.log

Descobri o processo que estava criando os arquivos e os matei:

user@fooserv:/local/data/plog $ ps -ef | grep 12077
user    12077     1  0 09:20 ?        00:00:00 /bin/bash /home/user/bin/process_big.sh /local/data/plog/process-one.log
user    12085 12077  0 09:20 ?        00:00:35 tail -f /local/data/plog/process-one.log
user    12088 12077  0 09:20 ?        00:01:31 grep ERR
user    12095 12077  0 09:20 ?        00:02:06 grep -v FIXME
user    12098 12077 61 09:20 ?        02:38:56 /bin/bash /home/user/bin/process_big.sh /local/data/plog/process-one.log
user    22836 32756  0 13:36 pts/0    00:00:00 grep 12077
user@fooserv:/local/data/plog $ kill 12098
user@fooserv:/local/data/plog $ kill 12100

Eu removi o arquivo:

usuário @ fooserv: / local / data / plog $ rm process-one.log

o df ainda diz que o diretório está cheio:

dm@fooserv:/local/data/plog $ df -l
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/rootvg-datavol
                    121790564 115659468         0 100% /local/data
   tmpfs                   102400      1028    101372   2% /var/asagent/lib/asagent
user@fooserv:/local/data/plog $

~

    

Answer 1

Tentando verificar se o processo ainda está sendo executado, o que está causando a retenção dos recursos do arquivo.

lsof -nP | grep '(deleted)'

Deve dar-lhe um ponto de partida.

    

Answer 2

Tem certeza de que você matou o processo certo? Parece que 12077 é aquele que abre / cria / mantém o arquivo em questão.

    

Answer 3

O Hymie provavelmente está certo - você matou o processo errado ou mais de um processo abriu o arquivo. A exclusão do arquivo removeu o inode da tabela de diretórios, mas o espaço não é liberado até que todo processo que usa o arquivo o feche. Não está bloqueado, por si só, mas há um contador que precisa ser zero antes que o espaço seja recuperado.

Experimente o lsof. E como você já removeu o arquivo, veja o que está aberto no diretório:

$ lsof + D / local / data / plog

Ou um dos outros encantamentos do lsof: link

    

Answer 4

Eu encontrei esta boa explicação aqui:

link

Como na resposta de RJ, lsof | grep deleted é de grande ajuda. Depois que eu identifiquei os criminosos principais (ou seja, dezenas de arquivos GB), usei echo > /proc/pid/fd/fd_number , onde pid e fd são identificados como no link acima.

Isso exigirá sudo. Além disso, uma reinicialização também ajuda.

O conselho vinculado foi particularmente útil, pois tínhamos uma restrição para não reiniciar a máquina.