Il m’arrive un truc bizarre sur un de mes serveurs : des dysfonctionnements apparaissent subitement (réception de mail notamment).
L’espace disque est correct :
Qd je me connecte en ssh j’ai néanmoins ce message indicatif :
zsh: locking failed for /root/.zsh_history: aucun espace disponible sur le périphérique: reading anyway
Dubitatif et ne trouvant rien qui justifie cette perte d’espace disque, j’augmente la taille de la partition racine (c’est un VPS), je redémarre et ça refonctionne.
Le soucis c’est que c’est la 2e fois que le problème survient.
Qu’est-ce qui pourrait occuper de la place sur la partition racine de façon cachée et comment le débusquer ?
C’est peut être juste le redémarrage qui fonctionne, et pas le redimensionnement ?
Tu n’as pas fourni le resultat de mount, mais la prochaine fois que tu as le message avec zsh, avant de redémarrer, vérifie avec mount que ta partition racine ne s’est pas remontée en lecture seule suite à une erreur (option remount-ro du mount):
comme ton /tmp et ton /run sont en ramdisk, il est possible que ton serveur continuer à tourner sans problème dans cet état malgré le ro de /, car plus besoin d’y écrire, à part pour les logs.
Un moyen de vérifier ça quand l’erreur n’est pas là serait de regarder s’il y a des trous dans un log qui parle tout le temps, comme syslog:
si tu vois que le log s’arrète à un moment et reprend longtemps aprés, genre quand tu as redémarré, c’est qu’il n’a pas pu écrire le log pendant la période de trou.
En effet la piste de l’épuisement des inodes disponibles est à vérifier si la création de nouveaux fichiers échoue (mais pas l’écriture dans un fichier existant).
Quel est le type de système de fichiers de la racine (ajouter l’option -T à df) ?
Si c’est ext4, le nombre d’inodes disponibles est fixé lors de la création et n’est pas augmenté par l’agrandissement du système.
Si c’est btrfs, sa gestion de l’espace libre est particulière et les valeurs affichées par df ne sont pas forcément justes.
Ni l’un ni l’autre n’est en ramdisk (périphérique bloc en mémoire).
/run est en tmpfs (système de fichiers en mémoire virtuelle) comme c’est l’usage.
/tmp est en loop donc probablement dans un fichier image sur disque (ce dont je ne vois pas l’intérêt).
Hors cas très particulier, l’usage d’un ramdisk pour un système de fichiers est devenu complètement obsolète depuis l’introduction de tmpfs qui offre de nombreux avantages :
pas besoin de formater
beaucoup plus rapide
n’alloue que la quantité de mémoire réellement occupée par le contenu à la hausse et à la baisse (le pilote ramdisk supportait l’option discard mais cela ne libère pas l’espace mémoire déjà alloué)
Pour tmp, j’avais mal vu le loop, mais quand je dis ramdisk, je pense filesystem en mémoire, donc j’y inclus le tmpfs, c’est ça que je voulais dire, désolé de l’abus de langage.
Ce que je voulais dire aussi, c’est que même avec / en ro, les écritures qui pourraient faire planter les services n’ecrivent pas sur / avec /tmp et /run séparés.
Merci pour vos différentes réponses !
Effectivement la piste des inodes me semble intéressante.
Il m’indique 67% d’utilisation après le redémarrage de ce matin et la partition est en ext4
Par contre je ne vois pas trop comment faire pour m’en sortir car supprimer des petits fichiers, OK, mais comment je les trouves, et comment être sûr qu’ils ne sont pas utiles ?
Pour le /tmp il est en effet sur une partition séparée pour bénéficier du paramètre nodev.
Pour le paramètre loop, c’est une bonne question ! J’ai du trouver ça sur un tuto il y a longtemps et je l’ai mis sans en saisir le sens (ça vous arrive vraiment jamais à vous ? ).
Je vais me renseigner et le virer si besoin.
Pour les inodes, aujourd’hui j’en suis à 68%, donc légère augmentation.
Grace à la commande find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n
… j’ai pu repérer le répertoire gourmand : /var/lib/php/sessions
J’ai mis en place un cron qui fait le nettoyage régulièrement.
Je pense que mon soucis va être résolu
Non, jamais. Je n’applique pas une instruction que je ne comprends pas. Si le tutoriel n’explique pas assez, je vais systématiquement chercher des informations supplémentaires dans les pages de manuel ou autres documentations.
).