web-dev-qa-db-fra.com

Aucun espace laissé sur l'erreur de périphérique, mais DF rapporte que davantage d'espace disponible

Mon PHP sessions sur mon service Web Debian à l'aide d'Apache2 avec mod_php semble échouer au hasard, affirmant 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:

ls /tmp

Il suffit de suspendre pour toujours, alors c'est mauvais.

Mais lorsque je vérifie l'espace libre et vérifie que l'utilisation de l'inode 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 bien. Bien sûr, 85% est plus que je voudrais, mais ce n'est pas 99% ou quoi que ce soit.

Je soupçonnais que c'était un problème pour ne pas redémarrer la machine pendant 5 ans et peut-être la création de nombreux petits fichiers, mais les informations d'Inode que je reçoivent un peu contradictent cela. Où devrais-je enquêter à la place?

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
8
Kzqai

Parfois, le système de fichiers endommagé peut faire des effets comme celui-ci - par exemple lorsque le répertoire/TMP est endommagé. Ou - quand il y a beaucoup de fichiers.

Pour "rapide" correction:

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

Si cela aide - essayez le système de redémarrage et le système de fichiers racine FSCK. Si c'est OK, il suffit de supprimer le répertoire /tmp.xxx.

Une autre possibilité est - lorsque/TMP est "Autre" partition ou TMPFS (vue sur Linux VSERVERS) - mais ce n'est pas montré par DF ​​(car df obtenir la liste des partitions de/etc/mtab, ce qui n'est parfois pas correct). Essayez de vérifier l'espace disque directement sur TMP par commande:

df /tmp
df -i /tmp

Autre option qui aide généralement aux sessions - il utilise un autre mécanisme de session. Si vous avez beaucoup de sessions temporaires, ce qui n'a pas besoin d'être très persistant - je vous recommanderais d'utiliser MemCache pour le stockage de session. Configuration Il est très simple - Vous devez installer PHP-MemCache, Memcached, puis dans PHP.CONF Configurer:

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

Ensuite, des sessions seront stockées dans MemCache jusqu'à la taille définie. sur elle - plus ancienne sera supprimée automatiquement.

2
undefine

Pour moi, changer fs.inotify.max_user_watches a fait le tour.

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

Correction de la valeur modifiée dans /etc/sysctl.conf

1
Xael