web-dev-qa-db-ja.com

デバイスエラーにスペースが残っていませんが、dfは使用可能なスペースが多いと報告します

私のPHP mod_phpでApache2を使用する私のDebianウェブサーバー上のセッションは、それらを書き込むスペースがないと言って、ランダムに失敗しているようです：

Sudo tail -60 /var/log/Apache2/error.log
[Fri Jan 30 15:55:35 2015] [error] [client xxx.xxx.xxx.xxx] PHP Warning:  session_start() [<a href='function.session-start'>function.session-start</a>]: open(/tmp/sess_555555555555555555, O_RDWR) failed: No space left on device (28) in /path/to-first-session-use/core/bootstrap.php on line 18

私がしようとすると：

ls /tmp

永久にハングアップするだけなので、それは悪いことです。

しかし、空き容量を確認し、inodeの使用が妥当であることを確認すると...

$ df -h

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             150G  121G   22G  85% /
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                   10M   16K   10M   1% /dev
tmpfs                 2.0G  4.0K  2.0G   1% /dev/shm

$ df -i

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1            19922944 11143605 8779339   56% /
tmpfs                 513524       4  513520    1% /lib/init/rw
udev                  513524     135  513389    1% /dev
tmpfs                 513524       3  513521    1% /dev/shm

数字は問題ないようです。確かに、85％は私が望む以上のものですが、それは99％でも何でもありません。

5年間マシンを再起動しなかったため、問題が発生したのではないかと思っていました。おそらく、多数の小さなファイルが作成されていますが、iノードの情報が多少矛盾しています。代わりにどこを調査すればよいですか？

編集：

ls -l /

drwxrwxrwt   4 root root 692M Feb  1 11:09 tmp/
drwxr-xr-x  10 root root 4.0K Jan  1  2013 usr/
drwxr-xr-x  14 root root 4.0K Oct  7  2010 var/
...etc
debiandisk-space-utilizationsessioninodetmp
8
Kzqai

/tmp/ディレクトリ自体が古いPHPクリーンアップされていないセッションでいっぱいになっている可能性があります。つまり、問題の原因が/tmp/ディレクトリ自体に分離されている可能性があります。その場合はすべての/tmp/sess_*ファイルを削除するだけです。まず、次のようにすべてのsess_*ファイルをリストします。

ls -la /tmp/sess_*

または、次のようにwcを使用してカウントを取得できます。

ls -la /tmp/sess_* | wc -l

ここで、いくつかの非常に多くのファイルがあることを確認したら、次のコマンドを実行して/tmp/sess_*ファイルを削除します。

Sudo rm -rf /tmp/sess_*

そして、一時的なセッションファイルは吹​​き飛ばされます。

しかし、別のブルートフォース（ただし比較的安全）で対処するには、/tmpディレクトリ自体を削除し、/tmpディレクトリを再作成してサーバーを再起動します。

/tmpディレクトリは、基本的にはキャッシュされた素材のコーディング保持ペンであるため、そこにあるべき有効なものはありません。したがって、私の最善のアドバイスは、次のコマンドを実行して/tmpディレクトリを削除して再構築することです。

rm -rf /tmp && mkdir /tmp/ && chown root:root /tmp && chmod 1777 /tmp

これで、1つのライナーは基本的に&&で接続されたシェルコマンドのリストであり、最初に/tmpを削除し、/tmpを再作成し、/tmpの所有権をroot:rootに戻し、次に/tmpディレクトリに適切な権限を設定します。その方法で実行する方が安全だと思われる場合は、必要に応じて各コマンドを1つずつ実行できます。

Sudo rm -rf /tmp 
Sudo mkdir /tmp
Sudo chown root:root /tmp
Sudo chmod 1777 /tmp

それが完了したら、サーバーを再起動することをお勧めします。物事は再び穏やかに片付ける必要があります。

7
JakeGould

時々損傷したファイルシステムはそれのような効果をすることができます-例えばディレクトリ/ tmpが損傷したとき。または-多くのファイルがある場合。

「迅速な」修正：

mv /tmp /tmp.xxx
mkdir /tmp
chmod a+rwxt /tmp

問題が解決しない場合は、システムとfsckルートファイルシステムを再起動してください。よろしければ、/ tmp.xxxディレクトリを削除してください。

別の可能性は-/ tmpが「その他の」パーティションまたはtmpfs（Linux vserversで見られる）の場合ですが、dfでは表示されません（dfが/ etc/mtabファイルからパーティションのリストを取得するため、正しくない場合があります）。次のコマンドを使用して、tmpのディスク容量を直接確認してください。

df /tmp
df -i /tmp

通常はセッションに役立つ他のオプション-他のセッションメカニズムを使用します。非常に永続的である必要のない多くの一時セッションがある場合、セッションの保存にmemcacheを使用することをお勧めします。設定は非常に簡単です。php-memcache、memcachedをインストールし、php.confに設定する必要があります。

session.save_handler = memcache
session.save_path="tcp://server:port?persistent=1&weight=1&timeout=1&retry_interval=15"

次に、セッションは定義されたサイズまでmemcacheに保存されます。それ以上-最も古いものが自動的に削除されます。

2
undefine

私にとっては、fs.inotify.max_user_watchesを変更することでうまくいきました。

root@grostruc:/# service ssh restart
Error: No space left on device
root@grostruc:/# sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 65536
root@grostruc:/# sysctl fs.inotify.max_user_watches=262144
fs.inotify.max_user_watches = 262144
root@grostruc:/# service ssh restart

/etc/sysctl.confの変更された値を修正

1
Xael