Partager via

Panique du noyau dans les machines virtuelles Linux Azure

  • Article

Cet article décrit plusieurs conditions qui peuvent entraîner une panique du noyau et fournit des conseils de résolution des problèmes.

En général, une panique du noyau est une situation où le noyau n’est pas en mesure de se charger correctement, et par conséquent, le système ne parvient pas à démarrer. Une autre forme de panique du noyau se produit lorsque le noyau rencontre une situation qu’il ne sait pas gérer et se protège en s’arrêtant.

Configuration requise

Assurez-vous que la console série est activée et fonctionnelle sur la machine virtuelle Linux.

Comment identifier une panique de noyau ?

Utilisez la Portail Azure pour afficher la sortie du journal de la console série de la machine virtuelle dans le panneau diagnostics de démarrage, le panneau de console série ou l’interface CLI AZ pour identifier la chaîne de panique du noyau spécifique.

Une panique du noyau ressemble à la sortie ci-dessous et s’affiche à la fin du journal de la console série :

Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
[  300.206297] Kernel panic - xxxxxxxx
[  300.207216] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G               ------------ T 3.xxx.x86_64 #1

Voici quelques-uns des événements de panique de noyau les plus courants :

Message de panique Reason
Oups : 0000 [#1] SMP » (case activée journal pour plus d’informations) Système paniqué en raison de déréférencement d’une mauvaise adresse.
SysRq : déclencher un crashdump Le vidage principal a été lancé par l’utilisateur avec sysrq-c ou en écho c dans /proc/sysrq-trigger.
bogue du noyau à <pathname/filename> :<line number> ! Ce format est la norme pour un bogue ayant échoué case activée (qui est semblable à un ASSERT, mais la logique est inversée). Le nom de fichier et le numéro de ligne indiquent quel bogue case activée a échoué.
Panique du noyau - Non synchronisation : verrouillage souple : tâches bloquées Le détecteur de verrouillage logiciel a trouvé un processeur qui n’a pas planifié la tâche de surveillance dans le seuil de verrouillage logiciel.
Panique du noyau - Non synchronisation : Un agent de surveillance a détecté un verrouillage dur sur le processeur 0 Le détecteur de verrouillage physique a trouvé un processeur qui n’a reçu aucune interruption hrtimer dans le seuil de verrouillage dur.
Panique du noyau - pas de synchronisation : hung_task : tâches bloquées L’agent de surveillance des tâches bloquées a détecté au moins une tâche qui était dans un état ininterruptible pour plus que la valeur du délai d’expiration de la tâche bloquée.
Panique du noyau - pas de synchronisation : mémoire insuffisante. panic_on_oom est sélectionné Le système est à court de mémoire et d’échange et a été forcé de commencer à tuer les processus pour libérer de la mémoire (et non le comportement par défaut).
Panique du noyau - pas de synchronisation : mémoire insuffisante et aucun processus tuable... Le système a été à court de mémoire et d’échange et a tué les processus pour libérer de la mémoire, mais il n’a plus de processus à tuer.
Panique du noyau - Non synchronisation : une NMI s’est produite. Pour plus d’informations, consultez le journal de gestion intégré. Un agent de surveillance a intercepté un NMI (interruption non masquable).
Panique du noyau - Non synchronisation : erreur IOCK NMI : Ne pas continuer Le système a reçu une NMI d’E/S case activée du matériel (pas une erreur de parité de mémoire) et kernel.panic_on_io_nmi a été défini (pas la valeur par défaut).
Panique du noyau - Non synchronisation : NMI : Ne pas continuer Le système a reçu une NMI (erreur de parité matérielle ou mémoire) et kernel.panic_on_unrecovered_nmi a été défini (pas la valeur par défaut).
Panique du noyau - pas de synchronisation : nmi watchdog Le système a reçu une NMI et kernel.panic_on_timeout ou kernel.panic_on_oops a été défini (pas les valeurs par défaut).
Panique du noyau - pas de synchronisation : case activée de machine irrécupérable Un événement d’exception case activée machine a été déclenché pour une condition irrécupérable.
Panique du noyau - pas de synchronisation : Tentative de tuer init ! Le processus init est le premier processus à démarrer et ne doit jamais se terminer.

Scénario 1 : La panique du noyau se produit au moment du démarrage

Une panique du noyau au moment du démarrage empêche la machine virtuelle de terminer le processus de démarrage du système d’exploitation. Cela se produit chaque fois que la machine virtuelle est démarrée et n’autorise pas la connexion.

Ce type d’événement est généralement lié, mais sans s’y limiter :

Résolution pour le scénario 1

Pour faire face à ce type de panique du noyau, les approches suivantes peuvent être utilisées :

Méthode 1 : Utilisation de la console série Azure

Utilisez la console série Azure pour interrompre le processus de démarrage et sélectionner une version précédente du noyau, si disponible. De cette façon, la machine virtuelle pourra redémarr, puis vous pouvez utiliser l’une des méthodes suivantes pour résoudre le problème spécifique avec le noyau qui ne démarre pas :

Méthode 2 : réparation hors connexion à l’aide d’une machine virtuelle de secours

Si la console série Azure n’est pas disponible ou qu’aucun noyau précédent n’est disponible, vous avez besoin d’une machine virtuelle de secours/réparation pour effectuer une réparation hors connexion.

Utilisez la commande Réparer la machine virtuelle pour créer une machine virtuelle de réparation avec une copie du disque du système d’exploitation de la machine virtuelle cible attachée. Ensuite, utilisez chroot monter la copie des systèmes de fichiers du système d’exploitation dans la machine virtuelle de réparation. Après cela, essayez les méthodes suivantes pour résoudre les problèmes de noyau :

Scénario 2 : Panique du noyau au moment de l’exécution

Ce type de panique du noyau est généralement déclenché à des moments imprévisibles après la fin du processus de démarrage du système d’exploitation et provoque l’arrêt de la réponse de la machine virtuelle, l’empêchant de se connecter. Il est généralement lié, mais sans s’y limiter :

Résolution pour le scénario 2

Pour faire face à ce type de panique du noyau, les approches suivantes peuvent être utilisées :

  • Passez en revue l’utilisation des ressources et les performances globales du système. La panique du noyau peut être liée à une éventuelle pénurie de ressources qui pourrait entraîner un redimensionnement de machine virtuelle.
  • Si possible, installez les dernières mises à jour disponibles dans les référentiels de distribution Linux correspondants. La panique du noyau peut être liée à des bogues connus dans le noyau ou d’autres logiciels.
  • Il est possible que la panique du noyau soit liée à une modification récente du noyau, auquel cas il est également recommandé de démarrer par rapport à une version précédente du noyau, comme expliqué dans Résolution pour le scénario 1.
  • Si les options ci-dessus ne sont pas applicables, il peut être nécessaire de configurer kdump et de générer un vidage principal à partager avec prise en charge pour une analyse plus approfondie.

Scénarios de panique de noyau plus spécifiques

Scénarios courants de panique du noyau avec des instructions de dépannage/récupération spécifiques :

Document Scénario
Une machine virtuelle Linux Azure sur un noyau 3.10 panique après une mise à niveau de nœud hôte Cet article décrit un problème qui se produit lorsqu’une machine virtuelle Linux Azure exécutant le noyau 3.10 se bloque après une mise à niveau de nœud hôte dans Azure.
Comment récupérer une machine virtuelle Linux Azure à partir de problèmes de démarrage liés au noyau Cet article fournit des solutions à un problème dans lequel une machine virtuelle Linux ne peut pas redémarrer après l’application des modifications du noyau.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.