Diskimi kim dolduruyor?

Birincil diskimi tamamen doldurdum:

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'nun kurulu olduğu birincil diskim:

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#

Bazı google arama yaptı ve kimin sorumlu olduğunu test etmek için bazı komutlar buldu, ancak kimin doldurduğunu anlayamıyorum:

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

Görünüşe göre diskimin 84G'sini dolduracak kadar büyük bir dosya veya dizin yok.

Birkaç gün önce diskin çıldırmış .xsession hataları nedeniyle dolu olduğunu gördüm. Ben ubuntu bilinen bir hata olduğunu buldum ve her on dakikada bir .xsession-hatalar silmek bir crontab hattı oluşturma çözüldü. Aslında şu an ev dizinimde artık yok.

Herhangi bir yardım lütfen?

Cronjob'ınızla ilgili sorun .xsession_errorsbüyük olasılıkla hala bazı uygulamalar veya sistem hizmetleri tarafından açılmış olmasıdır, bu yüzden silindiğinde dosya sistemi tablosundan gizlenecektir, ancak yine de diskte ve hala hatalar yazılacaktır.
Yani diski dolduracak, ama artık göremiyorsunuz.

@rinzwind tam olarak bu davranışı hedefler (doğru) cronjob kaldırmak ve hataları aramak için önerdiğinde. Bu sorunu doğru bir şekilde çözmenin tek yolu budur.

Geçici bir çözüm olarak, .xsession_errorsdosyayı aşağıdaki gibi bir cronjob ile kesebilirsiniz :

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

Ancak bunu yapmadan önce, bu hata mesajlarını oluşturan temel sorunları düzeltmeye çalışmalısınız. .xsession_errors

Diskimi kim dolduruyor?

bunu yaptığınızdan beri ...

Ben ubuntu bilinen bir hata olduğunu buldum ve her on dakikada bir .xsession-hatalar silmek bir crontab hattı oluşturma çözüldü

bu soruya cevap vermek imkansız.

Görmemiz gereken hataları bize bildirmek için lütfen aşağıdakileri uygulayın:

• Eklediğiniz ve kaldırılan crontab satırını kaldırın .xsessions_errors.
• Yeniden Başlatma ve sonra dolduruyor ne komut satırından kontrol .xsessions_errorskullanarak tail -f 100 ~/.xsessions_errors.
• Tekrarlanan herhangi bir sorun bulduğunuzda, birçoğunu sorunuza kopyalayın.
• Sisteminizi kullanabilmeniz için crontab satırını ekleyin.
• Sorunun giderilmesini bekleyin ve uygulayın. Ardından crontab satırını tekrar kaldırın ( .xsessions_errorsdosyanın silinmesinden daima kaçınılmalıdır).

(Kök olarak) df -g /some/partition_rootve du -gx /some/partition_root( -xdu'ya aynı bölümle sınırlandırılmasını söyler), örneğin '/' öğesini kontrol etmek için faydalıdır ) büyük bir fark varsa (örneğin, yüzde birkaçdan fazla): muhtemelen dosyalar var bazı işlemlerin hala yazdığını, ancak diskte sildiğinizi (dolayısıyla: işlemler tarafından açıldığı sürece hala var olduğunu ve disk alanını doldurduğunu (df -g bunu görür), ancak yok inode'larına daha uzun bağlantılar (veya dosya adları), du -gx onları özlüyor.

Sizin durumunuzda, çıktılarını karşılaştırın:

df -g /
du -gx /

1'den daha az bağlantısı olan dosyaların hangileri olduğunu öğrenmek için (örneğin, silinmiş ancak açılmış dosyalar):

lsof -nP +L1  /

Bu "hayalet" dosyalara yazılan işlemlerin hangileri olduğunu görmek için işlem adlarını ve pids'i kontrol edin ve buna göre hareket edin (bazıları durdurabilir / başlatabilir ve durdurulduklarında dosya serbest bırakılır ve alanı boşalır, diğerleri uygun bir yeniden başlatma gerektirebilir)