だから今日私はGUIプログラムがエラーメッセージを生成したことを発見しました:
(FreeFileSync:21930): dconf-CRITICAL **: 11:46:39.475: unable to create file '/run/user/1000/dconf/user': No space left on device. dconf will not work properly.
ここで/run/user/1000
、aはtmpfs
ユーザーのrun
フォルダです。問題は、上記の空き容量が十分であるということです。
$ df -h /run/user/1000
Filesystem Size Used Avail Use% Mounted on
tmpfs 1.6G 120K 1.6G 1% /run/user/1000
なぜ?その後、0
無料のinodeが残っていることがわかりました。
$ df -i /run/user/1000
Filesystem Inodes IUsed IFree IUse% Mounted on
tmpfs 2027420 2027420 0 100% /run/user/1000
とても良いです。しかし、問題は理由がまったく見つからないということです。あるからこのドライブにはほとんどファイルがありません。、次のようになります。
$ echo $PWD ; find . | wc -l
/run/user/1000
30
… …他にも開いているプログラムのうち、削除されたファイルをまだ維持するプログラムはほとんどありません。
$ sudo lsof $PWD | grep deleted
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
albert 17684 id 72u REG 0,69 1026 1200359 /run/user/1000/#1200359 (deleted)
Albertのみ。 Albertが終了しても、使用されたINodesの数(100%!)は変わりません。
Ubuntu 18.10。システムは長い間再起動せずに実行されました。まだ再起動していません。すぐにそうなります。エラーをクリアできることを確認してください。
[編集する]
du
ただし、以下は、報告されdf
た使用されたinodeの数に関連するコマンド間の出力の違いを示すリンクです。
https://gist.github.com/dreamcat4/6740c40bb313c1a016d35a0c00a8ab92
彼らは互いに矛盾しているようです!
ベストアンサー1
場合によっては、docker-containerがこれらのinode消費を引き起こす可能性があることがわかりました。
sudo find /run/docker/libcontainerd -xdev -printf '%h\n' |
sort | uniq -c | sort -k 1 -n | awk '$1 > 100'
26170 ./130663143dafaf23866942e29a72742d4f869edb0dfc40331e0e1782f4b14a3a
30472 ./5a7a4c88324c1a42a2e1ad835058347fab523d75481d2047ffabd4546c908873
30472 ./fc2a4628f61d1607861f3de9f1ce312fb662e57ffaa1205c2e616ff7aa54c67a
各コンテナを再起動すると、これらの値が合理的なレベルにリセットされます。