Kein Platz mehr auf Gerätefehler, aber df meldet, dass mehr Speicherplatz verfügbar ist

Meine PHP-Sitzungen auf meinem Debian-Webserver, auf denen Apache2 mit Apache2 verwendet wird, mod_phpscheinen zufällig fehlzuschlagen. Sie sagen, dass kein Platz zum Schreiben vorhanden ist:

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

Wenn ich versuche:

ls /tmp

Es hängt einfach für immer, also ist das schlecht.

Aber wenn ich den freien Speicherplatz überprüfe und überprüfe, ob die Inode-Nutzung angemessen ist ...

$ 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

Die Zahlen scheinen in Ordnung zu sein. Sicher, 85% sind mehr als ich möchte, aber es sind nicht 99% oder so.

Ich hatte den Verdacht, dass es ein Problem war, weil der Computer 5 Jahre lang nicht neu gestartet wurde und möglicherweise viele kleine Dateien erstellt wurden, aber die Inode-Informationen, die ich erhalte, widersprechen dem irgendwie. Wo soll ich stattdessen nachforschen?

Bearbeiten:

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

Es kann sein, dass das /tmp/Verzeichnis selbst mit veralteten PHP-Sitzungen gefüllt ist, die nicht bereinigt werden. Dies bedeutet, dass die Ursache der Probleme möglicherweise auf das /tmp/Verzeichnis selbst beschränkt ist. In diesem Fall würde ich einfach alle /tmp/sess_*Dateien entfernen . Listen Sie zunächst alle sess_*Dateien wie folgt auf:

ls -la /tmp/sess_*

Oder Sie können mit so zählen wc:

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

Sobald Sie eine Bestätigung erhalten haben, dass dort eine verrückte Anzahl von Dateien vorhanden ist, führen Sie diesen Befehl aus, um die /tmp/sess_*Dateien zu löschen :

sudo rm -rf /tmp/sess_*

Und die kurzlebigen Sitzungsdateien werden weggeblasen.

Eine andere brutale - aber relativ sichere - Möglichkeit, damit umzugehen, besteht darin, das /tmpVerzeichnis selbst wegzublasen, das /tmpVerzeichnis neu zu erstellen und den Server neu zu starten.

Da es sich bei dem /tmpVerzeichnis im Grunde genommen um einen Codierungs-Haltestift für zwischengespeichertes Material handelt, sollte nichts Gültiges darin enthalten sein. Mein bester Rat ist daher, den folgenden Befehl auszuführen, um das /tmpVerzeichnis zu entfernen und neu zu erstellen .

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

Jetzt, da ein Liner im Grunde genommen eine Liste von Shell-Befehlen ist, die durch &&diesen verbunden sind , werden zuerst gelöscht /tmp, neu erstellt /tmp, der Besitz von /tmpback to geändert root:rootund dann die richtigen Berechtigungen für das /tmpVerzeichnis festgelegt. Wenn Sie möchten, können Sie jeden Befehl einzeln ausführen, wenn Sie sich auf diese Weise sicherer fühlen.

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

Sobald dies erledigt ist, würde ich empfehlen, den Server neu zu starten. Die Dinge sollten wieder ruhig sein.

Manchmal kann ein beschädigtes Dateisystem ähnliche Effekte erzielen - beispielsweise wenn das Verzeichnis / tmp beschädigt ist. Oder - wenn es zu viele Dateien gibt.

Für "schnelle" Lösung:

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

Wenn dies hilft, starten Sie das System neu und fsck root file system. Wenn es in Ordnung ist, entfernen Sie einfach das Verzeichnis /tmp.xxx.

Eine andere Möglichkeit ist - wenn / tmp eine "andere" Partition oder tmpfs ist (auf Linux-Vservern zu sehen) -, aber nicht von df angezeigt wird (weil df eine Liste der Partitionen aus der Datei / etc / mtab erhält, die manchmal nicht korrekt ist). Versuchen Sie, den Speicherplatz direkt auf tmp mit dem folgenden Befehl zu überprüfen:

df /tmp
df -i /tmp

Eine andere Option, die normalerweise bei Sitzungen hilft - sie verwendet einen anderen Sitzungsmechanismus. Wenn Sie viele temporäre Sitzungen haben, die nicht sehr dauerhaft sein müssen, würde ich empfehlen, Memcache zum Speichern von Sitzungen zu verwenden. Die Konfiguration ist sehr einfach - Sie müssen php-memcache installieren, memcached und dann in der php.conf konfigurieren:

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

Dann werden - Sitzungen bis zur definierten Größe im Memcache gespeichert. darüber - das älteste wird automatisch entfernt.

Für mich hat das Ändern von fs.inotify.max_user_watches den Trick getan.

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

Korrigieren Sie den geänderten Wert in /etc/sysctl.conf