web-dev-qa-db-ja.com

この空き領域の絶え間ない損失を停止するにはどうすればよいですか？

通常どおりUbuntuを実行していましたが、突然1.2 GBの空き容量しかないというダイアログボックスが突然表示されました。 1時間前、30 GBの空き容量がありました。

いくつかのものを削除し、空き容量を最大25 GBにしました。しかし、それは減少し続けています。古いログファイルを削除してログファイルなどを切り詰めましたが、減少し続けています！

ディスクアナライザーを使用して、このすべての空き領域の損失がどこから発生しているのかを見つけようとしました。再起動し、最終的にUbuntuがディスクチェックを行って、空き容量を最大40 GBに戻しましたが、それでも1日あたり約10 GB減少し続けます。私はスペースを解放する新しい方法を探し続けていますが、それはディスクスペースを減らす自動化されたプロセスのようなもので、止めることはできません。

私は何をすべきかわかりません。原因を特定し、空き領域が減少しないようにするにはどうすればよいですか？

Sudo du -sh /var/* ~/.xsession-errorsからの出力は次のとおりです。

13M /var/backups
204M    /var/cache
112M    /var/crash
4.0K    /var/games
503M    /var/lib
4.0K    /var/local
0       /var/lock
9.5G    /var/log
85M     /var/mail
4.0K    /var/metrics
24K     /var/opt
0       /var/run
1.7M    /var/spool
391M    /var/tmp
11G     /var/tvmobili
20K     /var/www
224K    /home/school/.xsession-errors
hard-drivefilesystem
15
askcompu

制御不能なログがいくつかあります。毎日狂ったように削除する代わりに、急成長しているファイルを見つけて、look insideを見つけて、これが原因である可能性のあるものを調査します。何らかのプログラムが何らかの条件を記録するループで回転している可能性があります。そのプログラムを無効にするか、ログを無効にするか、不平を言っている状態を修正してください。

ファイルが目の前で大きくなっていて、どのプログラムがそのファイルに書き込んでいるのかわからない場合は、簡単に見つけることができます。以下に例を示します。誰が/var/log/syslogを開いていますか？ fuserコマンドを使用します。

# fuser /var/log/syslog
/var/log/syslog:      602

/var/log/syslogが開いているプロセスは1つだけです。それはプロセス602です。それは何ですか？ psとgrepを気にせずに、/procファイルシステムを直接見てみましょう。

# ls -l /proc/602/exe
lrwxrwxrwx 1 root root 0 Mar 29 17:45 /proc/602/exe -> /usr/sbin/rsyslogd

あぁ、それはrsyslogdです。 rsyslogdが/var/log/syslog/を開いていることに驚くことはありません。

この方法は機能することが保証されていません。その理由は、プログラムがファイルを開いたままにしておく必要がないからです。ファイルを開き、追加してから閉じるプロセスがあるとします。あなたはもう少し難しい調査になります。偶然 "red handed"プロセスをキャッチするまで、fuserを何度も実行できます。そのプロセス自体が急速に存在し、存在しなくなる可能性があります。別の問題は、複数のプロセスがファイルを開くことができるが、1つだけがファイルを大きくすることです。その場合、システムコールをトレースできます。

# fuser /var/log/huge-annoying-file
/var/log/huge-annoying-file:   1234 23459

おっと！ 1234と23459の2つのプロセスが開いています。それらが何をしているのか見てみましょう。

# strace -p 1234
Process 1234 attached - interrupt to quit
select(1, NULL, NULL, NULL, {9, 922666}

select呼び出しでブロックするだけで、何もしません。 Ctrl-Cを押してトレースを中断します。

select(1, NULL, NULL, NULL, {9, 922666}^C <unfinished ...>

次のものを確認してください：

# strace -p 23459
write(5, "Useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
write(5, "More useless garbage ..."..., 512) = 512
^C

おっと、1つは絶えず書いています。それは悪いものでなければなりません。プロセスが書き込むファイル記述子5が実際に大きなファイルであることも確認できます。

# ls -l /proc/23459/fd/5
lr-x------ 1 root root 64 Apr  3 23:39 /proc/23459/fd/5 -> /var/log/huge-annoying-file

破損したファイルシステムがあるとは思わないが、完全なチェックを強制するために、DVDを起動する必要はない。

まず、ファイルシステムの最大マウントカウント設定を確認します。 dfコマンドを使用してパーティションを特定します。ここにあるUbuntuシステムの例：

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda1       18062108 5499320  11645284  33% /
udev              392152       4    392148   1% /dev
tmpfs             159768     768    159000   1% /run
none                5120       0      5120   0% /run/lock
none              399416     200    399216   1% /run/shm
/dev/sr0           43668   43668         0 100% /media/VBOXADDITIONS_4.1.4_74291

/ファイルシステムが/dev/sda1にマウントされていることがわかります。したがって、/dev/sda1はルートパーティション（およびこの特定のシステムの唯一のパーティション）のストレージデバイスです。

そのファイルシステムのいくつかの属性を見てみましょう。これはマウントされていても安全です。このコマンドは大量の出力を出力します。抜粋は次のとおりです。

$ dumpe2fs /dev/sda1
dumpe2fs 1.42 (29-Nov-2011)
Filesystem volume name:   <none>
Last mounted on:          /
[ ... SNIP ... ]
Last mount time:          Fri Mar 29 17:45:18 2013
Last write time:          Tue Mar  5 09:08:03 2013
Mount count:              22
Maximum mount count:      22
[ ... SNIP ... ]

ちょっと見て、マウント数は最大マウント数に等しい。次回リブートすると、ファイルシステムのチェックが行われます。重要なことは、マウント数が正の値であることです。 yoursがゼロの場合、tune2fs -c 22 /dev/whateverを使用して22などの正の値に変更します。ゼロは、パーティションがマウントされている回数に関係なく、チェックが強制されないことを意味します。まれに再起動されるシステムの値はここで低くする必要があります。 1年に1度ダウンするサーバーは、リブートするたびにfsckを使用する可能性があります。日付ベースのチェック間隔も設定できます。

チェックを強制するには、実際のカウントを最大値以上にオーバーライドしてから再起動します。これは大文字のC：tune2fs -C 1234 /dev/whateverで行われます。これで、パーティションはチェックなしで1234回マウントされたように見えます。これは、1桁または2桁の最大値を超えています。

26
Kaz

ディスクチェックによりスペースの一部が解放され、この問題（またはその一部）がファイルシステムの破損によるものである可能性が示唆されました。その場合、ファイルシステムをスキャンして修復することにより、より多くのスペースを解放できるはずです。ただし、破損が永続的に発生している場合（場合によってはそうでない場合もあります）、それは通常、ハードドライブが死にかけていることを意味します。 バックアップ（ドキュメントや置換が困難な他の重要なファイル）が完全に最新ではない場合は、重要なものをすべてバックアップしてください！

and repairをチェックするには、ディスクをマウントできません（少なくとも読み書き不可）。したがって、ライブ環境（ライブCD/DVDまたはUSB）から修復ユーティリティを実行する必要があります。まず、ファイルを含むパーティションのデバイス名を見つける必要があります。

したがって、インストールされたシステムでを実行します。

mount | grep ' on / '

（/と'の間には必ずスペースを入れてください。）

次のようなものが得られます：

/dev/sda8 on / type ext4 (rw,errors=remount-ro)

onの前のテキスト（私のマシンの例では/dev/sda8-）は、ルートパーティションの完全なデバイス名（/）です。これを書き留めてください。必要になります。

次に、元々Ubuntuをインストールしたときと同じように、UbuntuデスクトップCD/DVDまたはUSBフラッシュドライブからコンピューターを起動します。 （これがWindowsインストーラーでインストールされたWubiシステムの場合、お知らせください。あなたが報告したことを考えると、私は期待していませんが、その場合、手順は異なる。）

Ubuntuをインストールせずに試す（Install Ubuntuではありません）を選択します。機能しているデスクトップが表示されたら、を押します Ctrl+Alt+T ターミナルウィンドウを開きます。次に、次のコマンドを実行します。

Sudo e2fsck -fkccp /dev/sda8

ただし、上記の方法で取得したように、/dev/sda8を/パーティションの正しい完全なデバイス名に置き換えてください。

これは時間がかかる場合があります。そのコマンドに含まれるcオプションは、ファイルシステムと同様にエラーのためにディスクの表面をスキャンします（そして、悪い領域を使用されないように悪い領域としてマークします）。必要に応じてccを省略できます（必要に応じてkも省略できます）。

e2fsckがそれらを修正しようとするとデータの損失を引き起こす可能性が高いと考える場合、特定の問題の修正についてプロンプトが表示される場合があります。 （pは、複雑さを引き起こすことなく修正できると確信している問題を修正するように作成します。）

のみを実行する必要があるため、必要に応じて修正できるようにすることを強くお勧めしますafterバックアップが最新であることを確認する、とにかく。プロンプトを表示せずに潜在的に危険な修正を試みる場合は、pをyに置き換えます。

この後、Ubuntuシステムを再起動して、スペースが解放されているかどうかを確認します。そうでない場合、または問題が続く場合は、質問をコメントして編集し、詳細を提供してください。

3
Eliah Kagan

この問題は解決されました。大量のログとtvmobiliエンコードファイルを書き込むファイアウォールでした。

0
askcompu