Comment résoudre le problème d'échec d'une opération du Gestionnaire de correctifs (Linux) ?

Lecture de 5 minute(s)
0

Je souhaite résoudre le problème d'échec de mon opération avec le Gestionnaire de correctifs (Linux).

Brève description

Les opérations d’application de correctifs peuvent échouer pour de multiples raisons, et la méthode employée pour corriger les erreurs dépend du système d’exploitation (OS) utilisé. Des messages d’erreur peuvent apparaître dans la console de gestion AWS ou dans la réponse d’API. Cependant, la sortie de la console est tronquée à 48 000 caractères, réduisant ainsi la visibilité de certains problèmes. Pour résoudre ces problèmes, une bonne pratique consiste à examiner la sortie complète enregistrée sur le nœud géré. Vous pouvez également utiliser la sortie envoyée à Amazon CloudWatch et à Amazon Simple Storage Service (Amazon S3) pour résoudre d’autres problèmes.

Résolution

Pour remédier aux messages d’erreur que vous pouvez recevoir en cas d’échec d’une opération du gestionnaire de correctifs (Linux), procédez comme suit.

Utiliser le dossier d’exploitation AWSSupport-TroubleshootPatchManagerLinux

Utilisez AWSSupport-TroubleshootPatchManagerLinux pour résoudre les échecs d’application des correctifs pour les nœuds gérés basés sur Linux.

Vérifier vos partitions et vos autorisations

L’erreur suivante s’affiche lorsque /var/lib/amazon est monté avec des autorisations noexec :

« /var/lib/amazon/ssm/<instanceid>/document/orchestration/<commandid>/PatchLinux/_script.sh: Permission deniedfailed to run commands: exit status 126 »

Pour résoudre ce problème, configurez les partitions exclusives sur /var/log/amazon et /var/lib/amazon, et montez-le avec des autorisations exec.

Vérifier les autorisations de vos nœuds gérés

Le message d’erreur suivant s’affiche généralement lorsque le nœud géré ne dispose pas des autorisations requises pour accéder au compartiment Amazon S3 spécifié :

« Unable to download payload: https://s3.DOC-EXAMPLE-BUCKET.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156 »

Pour résoudre ce problème, mettez à jour la configuration de votre réseau et vérifiez que vous pouvez atteindre le point de terminaison régional AWS Amazon S3. Pour en savoir plus, consultez la page  AWS Systems Manager Agent (SSM Agent) communications with AWS managed S3 buckets.

Vérifier vos tâches Exécuter la commande et votre espace de répertoire

Voici un exemple de message d’erreur qui peut s’afficher lorsque deux commandes exécutent simultanément AWS-RunPatchBaseline sur le même nœud géré. Vous pouvez également recevoir ce message d’erreur lorsqu’il n’y a pas d’espace disque disponible dans le répertoire /var.

Exemple d’erreur :

« IOError: [Errno 2] No such file or directory: ’patch-baseline-operations-X.XX.tar.gz’Unable to extract tar file: /var/log/amazon/ssm/patch-baseline-operations/patch-baseline-operations-1.75.tar.gz.
failed to run commands: exit status 155
Unable to load and extract the content of payload, abort.
failed to run commands: exit status 152"

Pour résoudre ce problème, procédez comme suit :

  • Assurez-vous qu’aucune fenêtre de maintenance ne comporte plus de deux tâches Exécuter la commande qui exécutent AWS-RunPatchBaseline. Les tâches ne peuvent pas avoir le même niveau de priorité et être exécutées sur les mêmes ID cibles. Modifiez les niveaux de priorité le cas échéant.
  • Assurez-vous qu’une seule association State Manager exécute AWS-RunPatchBaseline selon le même calendrier et cible les mêmes nœuds gérés.
  • Libérez de l’espace disque dans le répertoire /var.

Vérifier les processus qui s’exécutent sur un nœud géré

Le message d’erreur suivant s’affiche quand AWS-RunPatchBaseline s’exécute sur un nœud géré là où yum est déjà en cours d’exécution et où un autre processus a verrouillé la base de données :

« MM/DD/YYYY HH:MM:SS root [INFO]: another process has acquired yum lock, waiting 2 s and retry. »

Pour résoudre ce problème, procédez comme suit :

  • Vérifiez qu’aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration exécutant AWS-RunPatchBaseline selon un calendrier établi ne cible le même nœud géré simultanément.
  • Vérifiez qu’aucune opération manuelle yum ne s’exécute en même temps.

Vérifier la version Python du serveur

Voici un exemple de message d’erreur qui peut s’afficher quand aucune version prise en charge de Python 3 n’est installée sur l’instance Red Hat Enterprise Linux (RHEL), Debian Server, Raspberry Pi ou Ubuntu Server :

« An unsupported package manager and python version combination was found. Dnf requires Python 2 or Python 3 to be installed. »

Pour résoudre ce problème, installez une version de Python 3 (3.0 – 3.9) sur le serveur requis.

Vérifiez votre système d’exploitation

Voici un exemple de message d’erreur qui peut s’afficher lorsqu’un système d’exploitation n’est pas pris en charge :

"An error occurred (UnsupportedOperatingSystem) when calling the GetDeployablePatchSnapshotForInstance operation: patch_common.exceptions. PatchManagerError: (’Unsupported Operating System’, 146) »

Pour résoudre ce problème, utilisez un système d’exploitation compatible avec Patch Manager.

Vérifier la sortie de l’instance

Lorsque l’opération de correction a échoué et que la sortie de la console est tronquée, il se peut que vous ne puissiez pas afficher la sortie complète.

Pour résoudre ce problème, vérifiez l’intégralité de la sortie de l’instance à l’emplacement suivant :

« /var/lib/amazon/ssm/<example-instance-id>/document/orchestration/<example-command-id>/awsrunShellScript/PatchLinux/stdout »

Remarque : remplacez tous les exemples de chaînes par vos valeurs.

Vous pouvez également configurer l’opération pour envoyer la sortie Exécuter la commande à Amazon S3 ou CloudWatch.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an