Kto zapełnia mój dysk?

Mój główny dysk jest całkowicie zapełniony:

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 to mój podstawowy dysk, na którym jest zainstalowany 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#

Czy wyszukiwarka google znalazła kilka poleceń, aby sprawdzić, kto jest odpowiedzialny, ale nie mogę ustalić, kto ją wypełnia:

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:/#

Najwyraźniej nie ma żadnego pliku lub katalogu, który byłby tak duży, aby wypełnić 84G mojego dysku.

Kilka dni temu odkryłem, że dysk jest pełny z powodu błędów .xsession, które zwariowały. Odkryłem, że jest to znany błąd w Ubuntu i rozwiązałem tworzenie linii crontab, która co dziesięć minut usuwa błędy .xsession. W rzeczywistości nie mam go już w swoim katalogu domowym.

Proszę o pomoc?

Problem z cronjob polega na tym, że .xsession_errorsnajprawdopodobniej nadal jest otwierany przez niektóre aplikacje lub usługi systemowe, dlatego po usunięciu zostanie ukryty przed tabelą systemu plików, ale nadal znajduje się na dysku i nadal będą na nim zapisywane błędy.
Więc zapełni dysk, ale teraz już go nie widzisz.

@rinzwind dąży do tego właśnie zachowania, gdy (poprawnie) sugeruje usunięcie pracy z cronjobem i poszukiwanie błędów. To jedyny sposób, aby poprawnie rozwiązać ten problem.

W celu obejścia tego problemu można .xsession_errorsprzyciąć plik za pomocą narzędzia cronjob w następujący sposób:

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

Ale zanim to zrobisz, NAPRAWDĘ powinieneś spróbować naprawić podstawowe problemy, które powodują te komunikaty o błędach .xsession_errors

Kto zapełnia mój dysk?

skoro to robisz ...

Odkryłem, że jest to znany błąd w Ubuntu i rozwiązałem tworzenie wiersza crontab, który co dziesięć minut usuwa błędy .xsession-error

nie można odpowiedzieć na to pytanie.

Aby uzyskać informacje o błędach, które musimy zobaczyć, wykonaj następujące czynności:

• Usuń dodaną linię crontab, która usuwa .xsessions_errors.
• Reboot a następnie sprawdzić, z linii poleceń, co się zapełnia .xsessions_errorsużyciu tail -f 100 ~/.xsessions_errors.
• Gdy znajdziesz powtarzające się problemy, skopiuj niektóre z nich do pytania.
• Dodaj z powrotem linię crontab, aby móc korzystać z systemu.
• Poczekaj na rozwiązanie problemu i złóż wniosek. Następnie ponownie usuń linię crontab ( .xsessions_errorszawsze należy unikać usuwania pliku).

Kiedy występują duże różnice (powiedzmy, ponad kilka procent) między (jako root) df -g /some/partition_rooti du -gx /some/partition_root( -xkaże du ograniczyć się do tej samej partycji, przydatne do sprawdzenia '/' na przykład): prawdopodobnie nadal istnieją pliki otwarte, do którego niektóre procesy nadal zapisują, ale zostały usunięte na dysku (stąd: plik nadal istnieje, dopóki jest otwierany przez procesy i zapełnia przestrzeń dyskową (df -g to widzi), ale ponieważ nie ma dłuższe linki (lub nazwy plików) do swoich i-węzłów, du -gx tęskni za nimi.

W twoim przypadku porównaj wyniki:

df -g /
du -gx /

Aby dowiedzieć się, które pliki mają mniej niż 1 link (tzn. Pliki usunięte, ale nadal otwarte):

lsof -nP +L1  /

Sprawdź nazwy procesów i pid, aby zobaczyć, które procesy zapisują do tych plików „duchów”, i działaj odpowiednio (niektóre mogą być w stanie zatrzymać / uruchomić, a kiedy zostaną zatrzymane, plik zostanie zwolniony, a jego miejsce zwolnione, inni mogą wymagać odpowiedniego ponownego uruchomienia)