誰が私のディスクを満たしていますか？

プライマリディスクが完全にいっぱいになっています。

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が原因でディスクがいっぱいであることがわかりました。これはubuntuの既知のバグであることがわかり、10分ごとに.xsession-errorsを削除するcrontab行の作成を解決しました。実際、今のところホームディレクトリにはありません。

何か助けてください？

cronjobの問題は、.xsession_errors一部のアプリケーションまたはシステムサービスによってまだ開かれている可能性が高いため、削除されたときにファイルシステムテーブルから非表示になりますが、まだディスク上にあり、エラーが書き込まれます。
そのため、ディスクがいっぱいになりますが、現在は表示できません。

@rinzwindは、cronジョブを削除してエラーを探すことを（正しく）提案したときに、まさにこの動作を目指しています。これがこの問題を適切に修正する唯一の方法です。

回避策として、次の.xsession_errorsようなcronjobを使用してファイルを切り捨てることができます。

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

しかし、これを行う前に、実際にそれらのエラーメッセージを作成する根本的な問題を修正しようとする必要があります .xsession_errors

誰が私のディスクを満たしていますか？

あなたがこれをするので...

これはubuntuの既知のバグであることがわかり、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はそれを参照）が、そのiノードへのより長いリンク（またはファイル名）、du -gxはそれらを逃します。

あなたの場合、の出力を比較してください：

df -g /
du -gx /

リンクが1つ未満のファイル（つまり、削除されたファイルがまだ開かれている）を見つけるには：

lsof -nP +L1  /

プロセス名とPIDをチェックして、これらの「ゴースト」ファイルに書き込むプロセスがどれかを確認し、それに応じて動作します（停止/開始できるものもあります。停止すると、ファイルが解放され、そのスペースが解放されます。他の人は適切な再起動を必要とするかもしれません）