누가 내 디스크를 채우고 있습니까?

기본 디스크가 완전히 채워져 있습니다.

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/ dev / sda1은 ubuntu가 설치된 기본 디스크입니다.

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

구글 검색을하고 책임있는 사람을 테스트하는 명령을 찾았지만 누가 그것을 채우고 있는지 알 수 없습니다.

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

분명히 내 디스크의 84G를 채우기에 너무 큰 파일이나 디렉토리가 없습니다.

며칠 전 미쳤던 .xsession-errors로 인해 디스크가 가득 찼다는 것을 알았습니다. 나는 이것이 우분투에서 알려진 버그라는 것을 알았고 10 분마다 .xsession-errors를 삭제하는 crontab 줄을 만드는 것을 해결했습니다. 사실 지금은 더 이상 내 홈 디렉토리에 없습니다.

도와주세요?

cronjob의 문제는 .xsession_errors일부 응용 프로그램이나 시스템 서비스에서 여전히 열릴 가능성이 높기 때문에 삭제할 때 파일 시스템 테이블에서 숨겨 지지만 여전히 디스크에 있고 여전히 오류가 기록됩니다.
디스크를 채우지 만 더 이상 볼 수 없습니다.

@rinzwind는 (정확하게) cronjob을 제거하고 오류를 찾을 것을 제안 할 때이 동작을 정확하게 목표로합니다. 이것이이 문제를 올바르게 해결하는 유일한 방법입니다.

해결 방법으로 다음 .xsession_errors과 같이 cronjob으로 파일을 자를 수 있습니다 .

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

그러나이 작업을 수행하기 전에 오류 메시지를 생성하는 근본적인 문제를 해결해야합니다. .xsession_errors

누가 내 디스크를 채우고 있습니까?

당신이 이것을하기 때문에 ...

우분투에서 알려진 버그이며 10 분마다 .xsession-errors를 삭제하는 crontab 줄을 만드는 것을 해결했습니다.

이 질문에 대답하는 것은 불가능합니다.

다음 오류를 확인하여 필요한 오류를 확인하십시오.

• 추가 한 crontab 행을 제거하여 제거하십시오 .xsessions_errors.
• 재부팅 한 다음 명령 줄에서를 .xsessions_errors사용하여 채우는 내용을 확인하십시오 tail -f 100 ~/.xsessions_errors.
• 반복되는 문제를 발견하면 그 중 일부를 질문에 복사하십시오.
• 시스템을 사용할 수 있도록 crontab 라인을 다시 추가하십시오.
• 문제점에 대한 수정 사항을 기다렸다가 적용하십시오. 그런 다음 crontab 행을 다시 제거하십시오 ( .xsessions_errors파일 삭제 는 항상 피해야합니다).

(루트) df -g /some/partition_root와 du -gx /some/partition_root( -x예를 들어 '/'를 확인하는 데 유용한 동일한 파티션으로 제한하도록 du에게 알려줍니다) : 파일이 여전히있을 수 있습니다. 일부 프로세스가 여전히 쓰고 있지만 디스크에서 삭제했음을 나타냅니다 (따라서 파일이 프로세스에 의해 열려있는 한 파일이 존재하고 디스크 공간을 채우지 만 (df -g 참조)) 더 긴 링크 (또는 파일 이름)를 inode에 연결하면 du -gx에서 누락됩니다.

귀하의 경우 다음의 출력을 비교하십시오.

df -g /
du -gx /

링크가 1 개 미만인 파일 (즉, 삭제 된 파일이지만 여전히 열린 파일)을 찾으려면 다음을 수행하십시오.

lsof -nP +L1  /

프로세스 이름과 pid를 확인하여 "고스트"파일에 쓰는 프로세스를 확인한 후 그에 따라 조치를 취하십시오 (일부 중지 / 시작할 수 있으며 중지되면 파일이 해제되고 공간이 비워짐). 다른 사람은 적절한 재부팅이 필요할 수 있습니다)