제어 할 수없는 로그가 있습니다. 매일 미친 듯이 삭제하는 대신 빠르게 증가하는 파일을 찾아 내부를 조사하여 원인을 조사하십시오. 어쩌면 일부 프로그램이 루프 로깅 상태에서 회전하고 있습니다. 해당 프로그램을 비활성화하거나 로깅을 비활성화하거나 문제가되는 조건을 수정하십시오.
파일이 눈앞에서 커지고 있고 어떤 프로그램이 파일을 작성하고 있는지 모를 경우 쉽게 찾을 수 있습니다. 다음은 예입니다. 누가 /var/log/syslog열었습니까? 우리는 다음 fuser명령을 사용합니다 .
# fuser /var/log/syslog
/var/log/syslog: 602
하나의 프로세스 만 /var/log/syslog열려 있습니다. 프로세스 602입니다. 무엇입니까? psand로 귀찮게하지 말고 파일 시스템을 직접 grep살펴 보자 /proc.
# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd
아하 rsyslogd. 우리 rsyslogd는 /var/log/syslog/열린 것이 놀랍지 않습니다 .
이 방법은 작동하지 않을 수 있습니다. 그 이유는 프로그램이 파일을 쓰기 위해 파일을 열어 둘 필요가 없기 때문입니다. 파일을 열고 추가 한 후 닫는 프로세스가 있다고 가정하십시오. 좀 더 어려운 조사가있을 것입니다. fuser우연히 "빨간 손"프로세스를 잡을 때까지 여러 번 실행할 수 있습니다 . 그 과정 자체가 빠르게 존재하고 사라질 수 있습니다. 또 다른 문제는 여러 프로세스가 파일을 열 수는 있지만 하나만 커지게한다는 것입니다. 이 경우 시스템 호출을 추적 할 수 있습니다.
# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file: 1234 23459
죄송합니다! 1234와 23459의 두 가지 프로세스가 열려 있습니다. 그들이하는 일을 봅시다 :
# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}
아무것도하지 않고 select전화로 차단 합니다. Ctrl-C를 사용하여 추적을 중단하십시오.
select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>
다음을 확인하십시오.
# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C
죄송합니다. 계속 쓰고 있습니다. 나쁜 것이어야합니다. 프로세스가 작성하는 파일 디스크립터 5가 실제로 큰 파일인지 확인할 수 있습니다.
# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr 3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file
파일 시스템이 손상되었다고 생각하지는 않지만 완전히 검사하기 위해 DVD를 부팅 할 필요는 없습니다.
먼저 파일 시스템의 최대 마운트 수 설정을 검토하십시오. df 명령을 사용하여 파티션을 식별하십시오. 우분투 시스템의 예는 다음과 같습니다.
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 18062108 5499320 11645284 33% /
udev 392152 4 392148 1% /dev
tmpfs 159768 768 159000 1% /run
none 5120 0 5120 0% /run/lock
none 399416 200 399216 1% /run/shm
/dev/sr0 43668 43668 0 100% /media/VBOXADDITIONS_4.1.4_74291
/파일 시스템이에 마운트되어 있음을 알 수 있습니다 /dev/sda1. /dev/sda1루트 파티션 (이 특정 시스템의 유일한 파티션)의 저장 장치도 마찬가지 입니다.
해당 파일 시스템의 일부 속성을 살펴 보겠습니다. 마운트되어 있어도 안전합니다. 이 명령은 많은 출력을 뿜어냅니다. 발췌문은 다음과 같습니다.
$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name: <none>
Last mounted on: /
[ ... SNIP ... ]
Last mount time: Fri Mar 29 17:45:18 2013
Last write time: Tue Mar 5 09:08:03 2013
Mount count: 22
Maximum mount count: 22
[ ... SNIP ... ]
이봐, 마운트 수는 최대 마운트 수와 같습니다. 다음에 다시 부팅하면 파일 시스템 검사가 수행됩니다. 중요한 것은 마운트 횟수가 양수라는 것입니다. 0이 아닌 경우을 사용하여 22와 같은 양수 값으로 변경하십시오 tune2fs -c 22 /dev/whatever. 0은 파티션이 마운트 된 횟수에 관계없이 검사가 강제로 수행되지 않음을 의미합니다. 드물게 재부팅 된 시스템은이 값이 낮아야합니다. 1 년에 한 번 다운되는 서버는 재부팅 할 때마다 fsck를 사용할 수 있습니다. 날짜 기반 확인 간격도 설정할 수 있습니다.
이제 검사를 강제로 수행하기 위해 실제 개수를 최대 값 이상으로 재정의 한 다음 다시 부팅 할 수 있습니다. 그것은 자본으로 이루어집니다 C: tune2fs -C 1234 /dev/whatever. 이제 파티션은 검사없이 1234 번 마운트 된 것으로 보이며 최대 한 자릿수 또는 두 자릿수보다 큽니다.
sudo du -sh /var/* ~/.xsession-errors? (어리석은 것이 있으면 폭발 할 것으로 예상되는 두 곳). 그렇지 않으면 Eliah와 함께 있습니다. 디스크 문제를 나타냅니다. 이것을 진지하게 받아들이십시오.