Siapa yang mengisi disk saya?

Disk primer saya sudah terisi penuh:

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 adalah disk utama saya di mana ubuntu diinstal:

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#

Melakukan pencarian google dan menemukan beberapa perintah untuk menguji siapa yang bertanggung jawab, tetapi saya tidak tahu siapa yang mengisinya:

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

Ternyata tidak ada file atau direktori yang begitu besar untuk mengisi 84G disk saya.

Beberapa hari yang lalu saya menemukan bahwa disk penuh karena .xsession-errors yang menjadi gila. Saya menemukan ini adalah bug yang dikenal di ubuntu dan saya memecahkan membuat garis crontab yang setiap sepuluh menit menghapus .xsession-errors. Sebenarnya sekarang saya tidak memilikinya lagi di direktori home saya.

Tolong ada bantuan?

Masalah dengan cronjob Anda adalah bahwa .xsession_errorskemungkinan besar masih dibuka oleh beberapa aplikasi atau layanan sistem yang karenanya akan disembunyikan dari tabel sistem file ketika dihapus, tetapi masih ada di disk dan kesalahan masih akan ditulis untuk itu.
Jadi itu akan mengisi disk, tetapi sekarang Anda tidak bisa melihatnya lagi.

@rinzwind bertujuan untuk perilaku ini ketika dia (dengan benar) menyarankan untuk menghapus cronjob dan mencari kesalahan. Ini adalah satu-satunya cara untuk memperbaiki masalah ini dengan benar.

Sebagai solusinya Anda bisa memotong .xsession_errorsfile dengan cronjob seperti ini:

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

Tetapi sebelum melakukan ini, Anda BENAR-BENAR harus mencoba memperbaiki masalah mendasar yang membuat pesan kesalahan tersebut masuk .xsession_errors

Siapa yang mengisi disk saya?

sejak kamu melakukan ini ...

Saya menemukan ini adalah bug yang dikenal di ubuntu dan saya memecahkan membuat garis crontab yang setiap sepuluh menit menghapus .xsession-errors

tidak mungkin untuk menjawab pertanyaan ini.

Ikuti yang berikut ini untuk mendapatkan kesalahan yang perlu kami lihat:

• Hapus garis crontab yang Anda tambahkan yang menghapus .xsessions_errors.
• Reboot dan kemudian periksa dari baris perintah apa yang mengisi .xsessions_errorsmenggunakan tail -f 100 ~/.xsessions_errors.
• Ketika Anda menemukan masalah yang berulang banyak salinlah beberapa dari mereka ke dalam pertanyaan Anda.
• Tambahkan garis crontab kembali sehingga Anda dapat menggunakan sistem Anda.
• Tunggu perbaikan untuk masalah dan terapkan kemudian. Kemudian hapus baris crontab lagi (menghapus .xsessions_errorsfile harus selalu dihindari).

Ketika ada perbedaan besar (katakanlah, lebih dari beberapa persen) antara (sebagai root) df -g /some/partition_rootdan du -gx /some/partition_root( -xmemberitahu du untuk membatasi diri ke partisi yang sama, berguna untuk memeriksa '/' misalnya): mungkin masih ada file yang masih dibuka bahwa beberapa proses masih menulis, tetapi Anda menghapus pada disk (karenanya: file masih ada selama dibuka oleh proses, dan mengisi ruang disk (df -g melihat itu) tetapi karena tidak ada tautan yang lebih panjang (atau nama file) ke inode-nya, du -gx melewatkannya.

Dalam kasus Anda, bandingkan output dari:

df -g /
du -gx /

Untuk Mengetahui mana file dengan tautan kurang dari 1 (yaitu, file yang dihapus tetapi masih dibuka):

lsof -nP +L1  /

Periksa nama proses dan pids untuk melihat proses mana yang menulis ke file "ghost" itu, dan bertindak sesuai (beberapa Anda mungkin dapat menghentikan / memulai, dan ketika mereka dihentikan file akan dirilis dan ruangnya dibebaskan, yang lain mungkin memerlukan reboot yang benar)