Chi sta riempiendo il mio disco?

Ho il mio disco principale completamente riempito:

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 è il mio disco principale su cui è installato 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#

Ho fatto qualche ricerca su Google e ho trovato alcuni comandi per testare chi è il responsabile, ma non riesco a capire chi lo sta riempiendo:

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

Apparentemente non c'è nessun file o directory così grande da riempire l'84G del mio disco.

Alcuni giorni fa ho scoperto che il disco era pieno a causa di errori .xsession impazziti. Ho scoperto che questo è un bug noto in Ubuntu e ho risolto la creazione di una linea crontab che ogni dieci minuti eliminava gli errori .xsession. Infatti in questo momento non ce l'ho più nella mia directory home.

Qualche aiuto, per favore?

Il problema con il tuo cronjob è che .xsession_errorsmolto probabilmente è ancora aperto da alcune applicazioni o servizi di sistema, motivo per cui verrà nascosto dalla tabella del filesystem quando viene eliminato, ma è ancora sul disco e ancora gli errori verranno scritti su di esso.
Quindi riempirà il disco, ma ora non puoi più vederlo.

@rinzwind mira esattamente a questo comportamento quando (correttamente) suggerisce di rimuovere il cronjob e cercare gli errori. Questo è l'unico modo per risolvere correttamente questo problema.

Come soluzione alternativa potresti troncare il .xsession_errorsfile con un cronjob come questo:

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

Ma prima di farlo dovresti DAVVERO provare a risolvere i problemi sottostanti che creano quei messaggi di errore .xsession_errors

Chi sta riempiendo il mio disco?

dato che lo fai ...

Ho scoperto che questo è un bug noto in Ubuntu e ho risolto la creazione di una linea crontab che ogni dieci minuti elimina .xsession-errors

è impossibile rispondere a questa domanda.

Per ottenere gli errori che dobbiamo vedere, segui quanto segue:

• Rimuovi quella linea crontab che hai aggiunto che rimuove .xsessions_errors.
• Riavvia e quindi controlla dalla riga di comando cosa sta riempiendo .xsessions_errorsusando tail -f 100 ~/.xsessions_errors.
• Quando trovi problemi che si ripetono molto, copia alcuni di essi nella tua domanda.
• Aggiungi la linea crontab indietro in modo da poter usare il tuo sistema.
• Attendere una correzione per il problema e applicare quindi. Quindi rimuovere nuovamente la linea crontab (l'eliminazione del .xsessions_errorsfile deve essere sempre evitata).

Quando ci sono grandi differenze (diciamo, più di qualche percento) tra (come root) df -g /some/partition_roote du -gx /some/partition_root( -xdice a du di limitarsi alla stessa partizione, utile per controllare '/' per esempio): probabilmente ci sono ancora dei file aperto che alcuni processi stanno ancora scrivendo, ma che hai eliminato sul disco (quindi: il file esiste ancora fintanto che è aperto dai processi e riempie lo spazio su disco (df -g lo vede) ma poiché non ci sono collegamenti più lunghi (o nomi di file) ai suoi inode, du -gx li manca.

Nel tuo caso, confronta gli output di:

df -g /
du -gx /

Per scoprire quali sono i file con meno di 1 collegamenti (ovvero, file eliminati ma ancora aperti):

lsof -nP +L1  /

Controlla i nomi dei processi e i pid per vedere quali sono i processi che scrivono in quei file "fantasma" e agisci di conseguenza (alcuni potresti essere in grado di arrestare / avviare e quando vengono fermati il ​​file verrà rilasciato e il suo spazio liberato, altri potrebbero richiedere un corretto riavvio)