삭제되었지만 열린 로그 파일을 해제합니다.

삭제되었지만 열린 로그 파일을 해제합니다.

내 Debian 서버 디스크는 큰 postgresql 로그 파일로 인해 꽉 찼습니다. 삭제했지만 여전히 postgresql에 저장되어 있습니다. postgresql을 다시 시작하면 디스크가 가득 차서 소프트웨어를 시작할 수 없기 때문에 오류가 발생합니다. 다음은 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)

다른 스레드에서 제안한 명령 중 일부를 시도했지만 작동하지 않습니다. postgresql을 다시 시작하는 것이 작동하지 않는다는 것을 기억하고 이 파일을 삭제하는 방법을 제안할 수 있는 사람이 있습니까?

감사해요!

답변1

친구여, 당신에게는 디스크 부족보다 더 큰 문제가 있습니다!

이는 PostgreSQL의 대형 개체를 악용하는 사용자 정의 함수 취약점입니다. (lo_) 함수입니다.

내 서버에서는 포트 80을 통해 baby0119.com에 대한 프록시를 생성하는 트로이 목마입니다. postgres 포트 5432를 통해 postgres 사용자로 설치됩니다.

"postgres" 데이터베이스에 "exec111"이라는 함수가 있는지 확인하세요. \df+exec111.

이 기능을 삭제하고 pg_hba.conf, 방화벽 등을 강화하세요.

또한 실행된 명령이나 오류에 대한 postgresql 로그를 확인하세요.

/tmp의 상자에서 찾은 파일은 다음과 같습니다.

  • 6년 12월 7일 11:37 sjkpppp
  • 961472 12월 7일 16:36 testproxy6
  • 8088 12월 7일 16:36 testproxy.so

postgres 서버에서 실행 중인 웹 서버가 있는 경우 웹 액세스 로그를 확인하고 "proxytest" 또는 프록시에 대한 grep 등을 확인하세요.

답변2

또는 특별히 모험심이 강하다면, 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
% 

그러나 이는 작동할 수도 있고 작동하지 않을 수도 있으며 예상치 못한 방식으로 프로그램이 중단되어 탈모, 갑작스런 Windows 증후군,등.. 즉, 자신의 책임하에 사용하십시오. 단순히 프로그램을 종료하는 것이 일반적으로 더 나은 선택입니다.

핵심은 ( lsof또는 동등한 방법을 통해) 파일 설명자 번호를 얻는 것입니다. 여기에서 STDOUT_FILENO( 1wby lsof) 이것이 쉘이 리디렉션하는 것이므로 호출합니다.close(2)이 파일 설명자에. 프로그램 자체에서 연 파일은 더 높은 설명자 번호(3개 이상)를 가질 수 있습니다. 질문은 표준 오류가 /tmp파일로 이동함을 나타냅니다(이것은 아래에 정적 파일 이름이 기록된 로컬 보안 결함인 것으로 보입니다 /tmp).

답변3

어떤 이유로든 파일이 열려 있는 프로세스(활성 여부)가 여전히 존재합니다. 좀비가 아닌 경우 명시적으로(올바른 권한을 사용하여) 죽일 수 있습니다.

sudo kill -9 22712

답변4

1966머스탱의 대답이 맞습니다.

  1. 이는 일반적으로 Postgres 비밀번호가 너무 약하기 때문입니다.
  2. pg_hba.conf서버에 연결하기 위해 모든 IP를 신뢰하는지 확인하십시오 .

관련 정보