Résumé : les erreurs rapportées ci-dessous (et dans le titre) sont rares pour une machine virtuelle (peu de pages web en parle), je n'ai pas de solution à proposer et, dans mon cas, la machine virtuelle a totalement crashé deux mois après les premiers symptômes. Vérifie tes sauvegardes. :)
En juillet 2020, l'une de nos machines virtuelles Proxmox+KVM kernel-panic-ait, parfois plusieurs fois par jour. Puis ce comportement a disparu sans intervention humaine.
Début août 2020, /var passe en lecture seule. Je redémarre la VM, un fsck
se déclenche et la partition était à nouveau montée en écriture. Le lendemain, notre supervision m'indique que cette partition est à nouveau en lecture seule. dmesg
indique que la transition a eu lieu 256 minutes (4 h) après le démarrage. Les erreurs consignées sont :
kernel: sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_TIMEOUT,SUGGEST_OK
kernel: end_request: I/O error, dev sda, sector 29954432
kernel: Aborting journal on device sda7.
kernel: ext3_abort called.
kernel: EXT3-fs error (device sda7): ext3_journal_start_sb: Detected aborted journal
kernel: Remounting filesystem read-only
Pourquoi uniquement /var alors que toutes les partitions de cette machine virtuelle sont stockées dans le même LV LVM sur l'hyperviseur ? Car il s'agit d'un serveur, donc une fois qu'il a démarré et que les principaux binaires sont en RAM, il n'y a quasi plus de lecture et encore moins d'écriture sur /, alors que /var reçoit les journaux systèmes et applicatifs en permanence.
I/O wait côté hyperviseur ? Je n'y crois pas, car les graphes sur la page de résumé de l'hyperviseur dans l'interface web de Proxmox ne le montrent pas.
La VM n'a pas assez de temps CPU pour effectuer ses opérations car ses ressources CPU sont sous-dimensionnées ou que l'hyperviseur est débordé par d'autres VMs ? Je n'y crois pas, car top
affichait « 0,0 st » (st = steal time = temps volé). Mais comme je n'étais pas là au moment du passage en lecture seule… De plus, c'était les vacances, donc la charge de ce serveur était très réduite et aucun changement n'a été mis en œuvre par les administrateurs sur l'ensemble du périmètre (cette VM, l'hyperviseur, le réseau, etc.).
Très peu de ressources sur le web mentionnent les erreurs que je rencontre.
Je trouve la première partie des erreurs extraites de mon dmesg
dans un ticket chez VirtualBox.
La première piste est un problème d'I/O côté hyperviseur. Comme vu ci-dessus, aucun élément me permet d'affirmer cela.
La deuxième est de désactiver NCQ (optimisation des I/O en laissant le disque dur ordonnancer lui-même les requêtes afin de les traiter dans l'ordre de l'emplacement physique des données). Je n'y crois pas : 1) mes erreurs ne mentionnent pas NCQ ; 2) il y a trop d'abstractions (ext4 sur une partition étendue dans un LV LVM dans un volume RAID matériel) pour que NCQ puisse agir. J'ai quand même désactivé NCQ dans la VM.
Je trouve la deuxième partie des erreurs dans un rapport de bug chez Red Hat. Problème dans Linux censé avoir été corrigé à la fin des années 2000 mais qui est toujours là en 2013 et 2014… La version du système de notre VM date justement de la fin des années 2000, mais la version de notre noyau est ultérieure à celle dans laquelle le correctif est apparu.
Je me laisse convaincre que, peut-être, le journal ext est corrompu, ce qui explique le déclenchement automatique d'un fsck
à chaque redémarrage, même quand la partition /var n'a pas été remontée en lecture seule.
La partition /var étant utilisée par plein de processus, je ne peux pas travailler dessus. Je redémarre donc en single user mode (une entrée GRUB me le proposait, sinon il faut éditer la ligne et ajouter « single » à la fin de la ligne « linux » et démarrer en pressant ctrl+x) puis je tape les commandes suivantes proposées dans un commentaire du rapport de bug :
tune2fs -O ^has_journal /dev/sda7
fsck.ext4 -f /dev/sda7
tune2fs -j /dev/sda7
reboot
Vu que fsck
n'a pas trouvé d'erreur, je pense que tout cela a été vain.
Quoique… Cela a tenu un mois et demi.
Le serveur a totalement crashé mi-septembre 2020. Impossible de booter car absence de partition… Il semble qu'il ne s'agissait donc pas d'un problème temporaire type I/O wait / temps CPU volé, etc.
Un coup de testdisk
depuis un Live CD a permis de remettre la partition / dans le MBR, mais pas /var…
Nous avons monté une nouvelle machine virtuelle. La configuration du service a été récupérée depuis Bacula. Les données des utilisateurs du service étaient stockées dans un partage NFS. Aucune perte de données à déplorer.