내 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
( 1w
by lsof
) 이것이 쉘이 리디렉션하는 것이므로 호출합니다.close(2)
이 파일 설명자에. 프로그램 자체에서 연 파일은 더 높은 설명자 번호(3개 이상)를 가질 수 있습니다. 질문은 표준 오류가 /tmp
파일로 이동함을 나타냅니다(이것은 아래에 정적 파일 이름이 기록된 로컬 보안 결함인 것으로 보입니다 /tmp
).
답변3
어떤 이유로든 파일이 열려 있는 프로세스(활성 여부)가 여전히 존재합니다. 좀비가 아닌 경우 명시적으로(올바른 권한을 사용하여) 죽일 수 있습니다.
sudo kill -9 22712
답변4
1966머스탱의 대답이 맞습니다.
- 이는 일반적으로 Postgres 비밀번호가 너무 약하기 때문입니다.
pg_hba.conf
서버에 연결하기 위해 모든 IP를 신뢰하는지 확인하십시오 .