8 votes

Reynolds avatar

Erreur de manque d'espace sur le périphérique, mais df rapporte qu'il y a plus d'espace disponible.

Demandé el 30 de Janvier, 2015
Quand la question a-t-elle été
22251 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Mes sessions PHP sur mon serveur web Debian utilisant Apache2 avec mod_php semblent échouer de manière aléatoire, disant qu'il n'y a pas d'espace pour les écrire :

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

Quand j'essaie de le faire :

ls /tmp

Ça s'arrête toujours, donc c'est mauvais.

Mais quand je vérifie l'espace libre, et que l'utilisation des inodes est raisonnable...

$ 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

Les chiffres semblent bons. Bien sûr, 85% c'est plus que ce que j'aimerais, mais ce n'est pas 99% ou autre.

Je soupçonnais qu'il s'agissait d'un problème dû à l'absence de redémarrage de la machine pendant 5 ans et peut-être à la création d'un grand nombre de petits fichiers, mais les informations sur les inodes que je reçois contredisent cette hypothèse. Où devrais-je plutôt enquêter ?

Edit :

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
Demandé el 30 de Janvier, 2015 par Reynolds

Réponses

Trop de publicités?

7voto

Giacomo1968 avatar
Giacomo1968 Points 3512

Il se pourrait que le /tmp/ est lui-même rempli de sessions PHP périmées qui ne sont pas nettoyées, ce qui signifie que la source des problèmes peut être isolée dans le dossier de l'utilisateur. /tmp/ lui-même. Si c'est le cas, je supprimerais simplement tous les fichiers /tmp/sess_* fichiers. Tout d'abord, dressez la liste de tous les sess_* des dossiers comme celui-ci :

ls -la /tmp/sess_*

Ou vous pouvez compter avec wc comme ça :

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

Une fois que vous avez la confirmation qu'il y a un nombre incroyable de fichiers, exécutez la commande suivante pour supprimer les fichiers suivants /tmp/sess_* des fichiers :

sudo rm -rf /tmp/sess_*

Et les fichiers éphémères de la session seront explosés.

Mais un autre moyen brutal - mais relativement sûr - de gérer cela est de faire sauter le /tmp lui-même, recréez le répertoire /tmp et redémarrez le serveur.

Depuis le /tmp est en fait une sorte d'enclos de codage pour le matériel mis en cache, il n'y a rien de valide qui devrait s'y trouver. Donc mon meilleur conseil est d'exécuter la commande suivante pour supprimer et reconstruire le répertoire /tmp répertoire.

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

Maintenant, cette ligne est essentiellement une liste de Shell commandes reliées par && qui va d'abord supprimer /tmp recréer /tmp changer la propriété de /tmp retour à root:root puis définissez les permissions appropriées pour le /tmp répertoire. Si vous le souhaitez, vous pouvez exécuter chaque commande une par une si vous vous sentez plus en sécurité de cette façon.

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

Une fois que c'est fait, je recommande de redémarrer le serveur. Les choses devraient redevenir calmes et claires.

Répondu el 30 de Janvier, 2015 par Giacomo1968 (3512 Points )

2voto

undefine avatar
undefine Points 909

Parfois, un système de fichiers endommagé peut avoir des effets similaires - par exemple, lorsque le répertoire /tmp est endommagé. Ou lorsqu'il y a trop de fichiers.

Pour une solution "rapide" :

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

Si cela aide, essayez de redémarrer le système et de vérifier le système de fichiers racine. Si tout va bien, supprimez simplement le répertoire /tmp.xxx.

Une autre possibilité est - quand /tmp est une "autre" partition ou tmpfs (vu sur les serveurs linux) - mais il n'est pas montré par df (parce que df obtient la liste des partitions du fichier /etc/mtab qui parfois n'est pas correct). Essayez de vérifier l'espace disque directement sur tmp par la commande :

df /tmp
df -i /tmp

Une autre option, qui aide généralement les sessions, consiste à utiliser un autre mécanisme de session. Si vous avez beaucoup de sessions temporaires, qui n'ont pas besoin d'être très persistantes, je vous recommande d'utiliser memcache pour le stockage des sessions. La configuration est très simple - vous devez installer php-memcache, memcached et ensuite dans php.conf configurer :

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

Ensuite - les sessions seront stockées dans le memcache jusqu'à la taille définie. Au-delà - les plus anciennes seront automatiquement supprimées.

Répondu el 1 de Février, 2015 par undefine (909 Points )

1voto

Xael avatar
Xael Points 11

Pour moi, changer fs.inotify.max_user_watches a fait l'affaire.

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

Corriger la valeur modifiée dans /etc/sysctl.conf

Répondu el 17 de Juillet, 2015 par Xael (11 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X