Liberando um arquivo de log excluído, mas aberto

Question

meu disco do servidor Debian esgotou devido a um grande arquivo de log postgresql e, embora eu o tenha excluído, ele ainda é mantido pelo postgresql. Quando eu reinicio o postgresql, recebo um erro quando o disco está cheio e o software não pode ser iniciado. Este é o arquivo listado usando lsof + L1:

COMMAND     PID     USER   FD   TYPE DEVICE    SIZE/OFF NLINK    NODE NAME
testproxy 22712 postgres    2w   REG    8,1 15309393920     0 1184540 /tmp/postgresql-9.4-main.log (deleted)

Eu tentei alguns comandos sugeridos em outros tópicos, mas não está funcionando. Alguém pode sugerir como remover este arquivo, tendo em mente reiniciar o postgresql não está funcionando?

obrigado!

    

Answer 1

Por alguma razão, ainda existe um processo (ativo ou não) que tem o arquivo aberto. Se não é um zumbi, você pode matá-lo explicitamente (com as permissões certas):

sudo kill -9 22712

    

Answer 2

Você tem um problema maior do que Out of Disk, meu amigo!

Esta é uma exploração da Função Definida pelo Usuário que aproveita os objetos grandes do PostgreSQL. (lo_) funções.

No meu servidor, é um trojan que cria um proxy para baby0119.com na porta 80. Ele foi instalado como seu usuário postgres na porta 5432 do postgres.

Verifique seu banco de dados 'postgres' para uma função chamada 'exec111'. \ df + exec111.

Solte essa função, aperte o seu pg_hba.conf, firewall, etc.

Além disso, verifique no seu log postgresql os comandos emitidos ou ERRORs.

Os arquivos que encontrei na minha caixa em / tmp são:

• 6 7 de dezembro 11:37 sjkpppp
• 961472 Dez 7 16:36 testproxy6
• 8088 7 de dezembro 16:36 testproxy.so

Se você tiver um servidor web em execução no servidor postgres, verifique seus logs de acesso à web, grep para 'proxytest' ou proxy, etc.

    

Answer 3

Ou, se você estiver se sentindo particularmente arrogante, gdb !

% lsof | grep deleted | grep deleteme
% perl -E 'while(1){ say "om nom nom"; sleep 1 }' > deleteme & rm deleteme
[2] 15720
% lsof | grep deleted | grep deleteme                                     
perl      15720    jdoe42    1w      REG                8,2        0    5376141 /home/jdoe42/deleteme (deleted)
% gdb -q -p 15720
...
(gdb) call close(1)
$1 = 0
(gdb) quit
...
% lsof | grep deleted | grep deleteme
% jobs
[1]  - running    perl -E 'while(1){ say "om nom nom"; sleep 1 }' > deleteme
% kill %1
% 
[1]  + terminated  perl -E 'while(1){ say "om nom nom"; sleep 1 }' > deleteme
% 

Isso, no entanto, pode ou não funcionar, pode quebrar o programa assim manipulado de maneiras inesperadas, causar perda de cabelo, uso súbito da síndrome do Windows, et cetera . Em outras palavras, use a seu próprio risco. Simplesmente matar o programa será, na maioria das vezes, uma opção muito melhor.

Os principais pontos são obter o número do descritor de arquivo (por meio do lsof ou equivalente), que aqui é o STDOUT_FILENO ( 1w de acordo com lsof ) porque é isso que o shell redirecionou e, em seguida, chamar < href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/close.2"> close(2) nesse descritor de arquivo. Arquivos abertos pelo próprio programa provavelmente terão números de descritores mais altos (três e mais); a pergunta mostra que o erro padrão está indo para o arquivo /tmp (que parece ser uma falha de segurança local, para gravar um nome de arquivo estático em /tmp como esse).

    

Answer 4

1966A resposta de Mustang está certa.

1. Geralmente, isso ocorre porque sua senha do Postgres é muito fraca.
2. Verifique seu pg_hba.conf , se você confiar em todo o IP para conectar seu servidor.