• Le AWS Systems Manager CloudWatch tableau de bord ne sera plus disponible après le 30 avril 2026. Les clients peuvent continuer à utiliser CloudWatch la console Amazon pour consulter, créer et gérer leurs CloudWatch tableaux de bord Amazon, comme ils le font aujourd'hui. Pour plus d'informations, consultez la [documentation Amazon CloudWatch Dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résolution des problèmes de Patch Manager
Utilisez les informations suivantes pour résoudre les problèmes liés à Patch Manager, un outil de AWS Systems Manager.
**Topics**
+ [Problème : erreur « Invoke- PatchBaselineOperation : accès refusé » ou erreur « Impossible de télécharger le fichier depuis S3 » pour `baseline_overrides.json`](#patch-manager-troubleshooting-patch-policy-baseline-overrides)
+ [Problème : le correctif échoue sans cause apparente ni message d'erreur](#race-condition-conflict)
+ [Problème : résultats de conformité aux correctifs inattendus](#patch-manager-troubleshooting-compliance)
+ [Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Linux](#patch-manager-troubleshooting-linux)
+ [Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Windows Server](#patch-manager-troubleshooting-windows)
+ [Erreurs lors de l'exécution `AWS-RunPatchBaseline` sur macOS](#patch-manager-troubleshooting-macos)
+ [Utilisation des AWS Support runbooks d'automatisation](#patch-manager-troubleshooting-using-support-runbooks)
+ [En contactant AWS Support](#patch-manager-troubleshooting-contact-support)
## Problème : erreur « Invoke- PatchBaselineOperation : accès refusé » ou erreur « Impossible de télécharger le fichier depuis S3 » pour `baseline_overrides.json`
**Problème** : lorsque les opérations de correction spécifiées par votre politique de correction s'exécutent, vous recevez une erreur similaire à l'exemple suivant.
------
#### [ Example error on Windows Server ]
```
----------ERROR-------
Invoke-PatchBaselineOperation : Access Denied
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestr
ation\792dd5bd-2ad3-4f1e-931d-abEXAMPLE\PatchWindows\_script.ps1:219 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOpera
tion:InstallWindowsUpdateOperation) [Invoke-PatchBaselineOperation], Amazo
nS3Exception
+ FullyQualifiedErrorId : PatchBaselineOperations,Amazon.Patch.Baseline.Op
erations.PowerShellCmdlets.InvokePatchBaselineOperation
failed to run commands: exit status 0xffffffff
```
------
#### [ Example error on Linux ]
```
[INFO]: Downloading Baseline Override from s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json
[ERROR]: Unable to download file from S3: s3://aws-quicksetup-patchpolicy-123456789012-abcde/baseline_overrides.json.
[ERROR]: Error loading entrance module.
```
------
**Cause** : vous avez créé une politique de correctifs dans Quick Setup, et certains de vos nœuds gérés avaient déjà un profil d'instance attaché (pour les instances EC2) ou à une fonction du service (pour les machines non EC2).
Cependant, comme le montre l’image suivante, vous n’avez pas coché la case **Ajouter les politiques IAM requises aux profils d’instance existants attachés à vos instances**.
![\[\]](http://docs.aws.amazon.com/fr_fr/systems-manager/latest/userguide/images/QS-instance-profile-option.png)
Lorsque vous créez une politique de correctifs, un compartiment Amazon S3 est également créé pour stocker le fichier `baseline_overrides.json` de configuration de la politique. Si vous ne cochez pas la case **Ajouter les politiques IAM requises aux profils d'instance existants attachés à vos instances** lors de la création de la politique, les politiques IAM et les balises de ressources nécessaires pour accéder à `baseline_overrides.json` dans le compartiment S3 ne sont pas automatiquement ajoutées à vos profils d'instance et fonction du service IAM existants.
**Solution 1** : supprimez la configuration de la politique de correctifs existante, puis créez-en une nouvelle, en veillant à cocher la case **Ajouter les politiques IAM requises aux profils d'instance existants attachés à vos instances**. Cette sélection applique les politiques IAM créées par cette configuration Quick Setup aux nœuds auxquels un profil d'instance ou une fonction du service est déjà attaché. (Par défaut, Quick Setup ajoute les politiques requises aux instances et aux nœuds qui n'ont *pas* encore de profils d'instance ou de fonction du service.) Pour plus d'informations, consultez [Automatiser l'application de correctifs à l'échelle de l'organisation à l'aide d'une politique de correctifs Quick Setup](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html).
**Solution 2** : ajoutez manuellement les autorisations et les balises requises à chaque profil d'instance IAM et à chaque fonction du service IAM que vous utilisez avec Quick Setup. Pour obtenir des instructions, veuillez consulter [Autorisations pour le compartiment S3 de la politique de correctifs](quick-setup-patch-manager.md#patch-policy-s3-bucket-permissions).
## Problème : le correctif échoue sans cause apparente ni message d'erreur
**Problème** : une opération de correctif échoue sans renvoyer de message d'erreur.
**Cause possible** : lors de l'application de correctifs à des nœuds gérés, l'exécution du document peut être interrompue et marquée comme ayant échoué même si les correctifs ont été correctement installés. Cela peut se produire si le système lance un redémarrage inattendu pendant l'opération de correction (par exemple, pour appliquer des mises à jour au microprogramme ou à des fonctionnalités similaires SecureBoot). L'agent SSM ne peut pas conserver et reprendre l'état d'exécution du document lors de redémarrages externes, ce qui entraîne le signalement de l'échec de l'exécution. Cela peut se produire avec les `AWS-InstallWindowsUpdates` documents `AWS-RunPatchBaseline` `AWS-RunPatchBaselineAssociation``AWS-RunPatchBaselineWithHooks`,, et.
**Solution** : pour vérifier l'état de l'installation des correctifs après un échec d'exécution, exécutez une `Scan` opération de correction, puis vérifiez les données de conformité des correctifs dans le Gestionnaire de correctifs afin d'évaluer l'état de conformité actuel.
Si vous déterminez que les redémarrages externes ne sont pas à l'origine de l'échec dans ce scénario, nous vous recommandons de contacter [AWS Support](#patch-manager-troubleshooting-contact-support).
## Problème : résultats de conformité aux correctifs inattendus
**Problème** : lorsque vous examinez les informations de conformité aux correctifs générées après une opération `Scan`, les résultats incluent des informations qui ne reflètent pas les règles définies dans votre référentiel de correctifs. Par exemple, une exception que vous avez ajoutée à la liste **Rejected patches** (Correctifs rejetés) dans un référentiel de correctifs est répertoriée comme `Missing`. Ou les correctifs considérés comme `Important` sont répertoriés comme manquants alors que votre référentiel de correctifs ne spécifie que des correctifs `Critical`.
**Cause** : Patch Manager prend actuellement en charge plusieurs méthodes d'exécution des opérations `Scan` :
+ Une politique de correctifs configurée dans Quick Setup
+ Une option de gestion des hôtes configurée dans Quick Setup
+ Une fenêtre de maintenance pour exécuter un correctif `Scan` ou une tâche `Install`
+ Une opération **Patch now** (Appliquer les correctifs maintenant) à la demande
Lorsqu'une opération `Scan` s'exécute, elle remplace les informations de conformité issues de l'analyse la plus récente. Si plusieurs méthodes sont configurées pour exécuter une opération `Scan` et qu'elles utilisent des référentiels de correctifs différents avec des règles différentes, elles se traduiront par des résultats de conformité aux correctifs différents.
**Solution** : pour éviter des résultats inattendus de conformité aux correctifs, nous vous recommandons de n'utiliser qu'une seule méthode à la fois pour exécuter l'opération `Scan` de Patch Manager. Pour de plus amples informations, veuillez consulter [Identification de l'exécution qui a créé les données de conformité des correctifs](patch-manager-compliance-data-overwrites.md).
## Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Linux
**Topics**
+ [Problème : erreur indiquant « Pas de fichier ou de répertoire »](#patch-manager-troubleshooting-linux-1)
+ [Problème : erreur indiquant « un autre processus a acquis yum lock »](#patch-manager-troubleshooting-linux-2)
+ [Problème : erreur indiquant « Autorisation refusée /échec d'exécution des commandes »](#patch-manager-troubleshooting-linux-3)
+ [Problème : erreur indiquant « Impossible de télécharger la charge utile »](#patch-manager-troubleshooting-linux-4)
+ [Problème : erreur indiquant « gestionnaire de packages et combinaison de versions python non pris en charge »](#patch-manager-troubleshooting-linux-5)
+ [Problème : Patch Manager n'applique pas les règles spécifiées pour exclure certains packages](#patch-manager-troubleshooting-linux-6)
+ [Problème : l'application des correctifs échoue et Patch Manager signale que l'extension Indication de nom de serveur pour TLS n'est pas disponible](#patch-manager-troubleshooting-linux-7)
+ [Problème : Patch Manager signale « Plus de miroirs à essayer »](#patch-manager-troubleshooting-linux-8)
+ [Problème : le correctif échoue avec « Code d'erreur 23 renvoyé par curl »](#patch-manager-troubleshooting-linux-9)
+ [Problème : le correctif échoue avec le message « Error unpacking rpm package… » (Erreur de décompactage du package rpm…)](#error-unpacking-rpm)
+ [Problème : le correctif échoue avec le message « Erreur côté service lors du chargement de l’inventaire »](#inventory-upload-error)
+ [Problème : le correctif échoue avec le message « Errors were encountered while downloading packages » (Des erreurs ont été rencontrées lors du téléchargement des packages)](#errors-while-downloading)
+ [Problème : l'application des correctifs échoue en raison d'une erreur de mémoire insuffisante (OOM)](#patch-manager-troubleshooting-linux-oom)
+ [Problème : le correctif échoue avec le message suivant : « The following signatures couldn't be verified because the public key is not available » (Les signatures suivantes n'ont pas pu être vérifiées, car la clé publique n'est pas disponible)](#public-key-unavailable)
+ [Problème : l'application de correctifs échoue avec un message « NoMoreMirrorsRepoError »](#no-more-mirrors-repo-error)
+ [Problème : le correctif échoue avec un message « Unable to download payload » (Impossible de télécharger la charge utile)](#payload-download-error)
+ [Problème : le correctif échoue avec un message « install errors: dpkg: error: dpkg frontend is locked by another process » (erreurs d'installation : dpkg : erreur : dpkg frontend est bloqué par un autre processus)](#dpkg-frontend-locked)
+ [Problème : le correctif sur Ubuntu Server échoue avec une erreur « dpkg was interrupted » (dpkg a été interrompu)](#dpkg-interrupted)
+ [Problème : l'utilitaire du gestionnaire de packages ne peut pas résoudre la dépendance d'un package](#unresolved-dependency)
+ [Problème : échecs liés aux dépendances de verrouillage du package Zypper sur les nœuds gérés SLES](#patch-manager-troubleshooting-linux-zypper-locks)
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-linux-concurrent-lock)
### Problème : erreur indiquant « Pas de fichier ou de répertoire »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'une des erreurs suivantes.
```
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
```
**Cause 1** : deux commandes servant à exécuter `AWS-RunPatchBaseline` s'exécutaient en même temps sur le même nœud géré. Cela crée une condition de concurrence qui empêche la création des `file patch-baseline-operations*` temporaires, ou l'accès normal à celles-ci.
**Cause 2** : l'espace de stockage restant dans le répertoire `/var` est insuffisant.
**Solution 1** : assurez-vous qu'aucune fenêtre de maintenance ne comporte au moins deux Run Command tâches exécutées `AWS-RunPatchBaseline` avec le même niveau de priorité et exécutées sur la même cible IDs. Si tel est le cas, réorganisez la priorité. Run Commandest un outil dans AWS Systems Manager.
**Solution 2** : vérifiez qu'une seule fenêtre de maintenance à la fois exécute des tâches Run Command qui utilisent `AWS-RunPatchBaseline` sur les mêmes cibles et selon le même calendrier. Si tel est le cas, modifiez le calendrier.
**Solution 3** : vérifiez 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. State Manager est un outil d’ AWS Systems Manager.
**Solution 4** : libérez suffisamment d'espace de stockage dans le répertoire `/var` pour les packages de mise à jour.
### Problème : erreur indiquant « un autre processus a acquis yum lock »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
12/20/2019 21:41:48 root [INFO]: another process has acquired yum lock, waiting 2 s and retry.
```
**Cause** : le document `AWS-RunPatchBaseline` a commencé à s'exécuter sur un nœud géré alors qu'il est déjà en cours d'exécution dans une autre opération. Il a acquis le processus `yum` du gestionnaire de packages.
**Solution** : vérifiez qu'aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration qui exécute `AWS-RunPatchBaseline` selon une planification ne cible le même nœud géré en même temps.
### Problème : erreur indiquant « Autorisation refusée /échec d'exécution des commandes »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
sh:
/var/lib/amazon/ssm/instanceid/document/orchestration/commandid/PatchLinux/_script.sh: Permission denied
failed to run commands: exit status 126
```
**Cause** : `/var/lib/amazon/` peut être monté avec des autorisations `noexec`. Cela pose un problème car SSM Agent télécharge des scripts de charge utile dans `/var/lib/amazon/ssm` et les exécute depuis cet emplacement.
**Solution** : la vérification de la configuration des partitions exclusives est nécessaire pour `/var/log/amazon` et `/var/lib/amazon`, ainsi que leur montée avec des autorisations `exec`.
### Problème : erreur indiquant « Impossible de télécharger la charge utile »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
Unable to download payload: https://s3.amzn-s3-demo-bucket.region.amazonaws.com/aws-ssm-region/patchbaselineoperations/linux/payloads/patch-baseline-operations-X.XX.tar.gz.failed to run commands: exit status 156
```
**Cause** : le nœud géré ne dispose pas des autorisations requises pour accéder au compartiment Amazon Simple Storage Service (Amazon S3) spécifié.
**Solution** : mettez à jour votre configuration réseau pour que les points de terminaison S3 soient accessibles. Pour plus de détails, consultez les informations relatives à l'accès requis aux compartiments S3 pour Patch Manager dans [SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions).
### Problème : erreur indiquant « gestionnaire de packages et combinaison de versions python non pris en charge »
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline`, l'application des correctifs échoue avec l'erreur suivante.
```
An unsupported package manager and python version combination was found. Apt requires Python3 to be installed.
failed to run commands: exit status 1
```
**Cause** : aucune version prise en charge de python3 n’est pas installée sur l’instance Debian Server ou Ubuntu Server.
**Solution** : installez une version prise en charge de python3 (3.0 à 3.12) sur le serveur, comme l’exigent les nœuds gérés Debian Server et Ubuntu Server.
### Problème : Patch Manager n'applique pas les règles spécifiées pour exclure certains packages
**Problème** : vous avez tenté d'exclure certains packages en les spécifiant dans le fichier `/etc/yum.conf`, au format `exclude=package-name`, mais lors de l'opération `Install` de Patch Manager il s'avère qu'ils ne sont pas exclus.
**Cause** : Patch Manager n'incorpore pas les exclusions spécifiées dans le fichier `/etc/yum.conf`.
**Solution** : pour exclure des packages spécifiques, créez un référentiel de correctifs personnalisé et créez une règle pour exclure les packages que vous ne voulez pas installer.
### Problème : l'application des correctifs échoue et Patch Manager signale que l'extension Indication de nom de serveur pour TLS n'est pas disponible
**Problème** : l'opération d'application de correctifs émet le message suivant.
```
/var/log/amazon/ssm/patch-baseline-operations/urllib3/util/ssl_.py:369:
SNIMissingWarning: An HTTPS request has been made, but the SNI (Server Name Indication) extension
to TLS is not available on this platform. This might cause the server to present an incorrect TLS
certificate, which can cause validation failures. You can upgrade to a newer version of Python
to solve this.
For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
```
**Cause** : ce message n'indique pas une erreur. Il s'agit plutôt d'un avertissement selon lequel l'ancienne version de Python distribuée avec le système d'exploitation ne prend pas en charge l'indication de nom de serveur TLS. Le script de charge utile du correctif Systems Manager émet cet avertissement lors de la connexion à AWS APIs ce support SNI.
**Solution** : pour résoudre les échecs d'application de correctifs lorsque ce message est signalé, consultez le contenu des fichiers `stdout` et `stderr`. Si vous n'avez pas configuré la ligne de base de correctifs pour stocker ces fichiers dans un compartiment S3 ou dans Amazon CloudWatch Logs, vous pouvez les localiser à l'emplacement suivant sur votre nœud géré Linux.
`/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`
### Problème : Patch Manager signale « Plus de miroirs à essayer »
**Problème** : l'opération d'application de correctifs émet le message suivant.
```
[Errno 256] No more mirrors to try.
```
**Cause** : les référentiels configurés sur le nœud géré ne fonctionnent pas correctement. Les causes possibles incluent :
+ Le cache `yum` est corrompu.
+ Des problèmes liés au réseau empêchent d'atteindre une URL de référentiel.
**Solution** : Patch Manager utilise le gestionnaire de packages par défaut du nœud géré pour appliquer les correctifs. Vérifiez que les référentiels sont configurés et fonctionnent correctement.
### Problème : le correctif échoue avec « Code d'erreur 23 renvoyé par curl »
**Problème** : une opération d'application de correctifs qui utilise `AWS-RunPatchBaseline` échoue avec une erreur semblable à celle-ci :
```
05/01/2025 17:04:30 root [ERROR]: Error code returned from curl is 23
```
**Cause** : l'outil curl utilisé sur vos systèmes ne dispose pas des autorisations nécessaires pour écrire sur le système de fichiers. Cela peut se produire lorsque l'outil curl par défaut du gestionnaire de packages a été remplacé par une version différente, telle que celle installée avec snap.
**Solution** : si la version curl fournie par le gestionnaire de packages a été désinstallée lors de l'installation d'une autre version, réinstallez-la.
Si vous devez conserver plusieurs versions de curl installées, assurez-vous que la version associée au gestionnaire de packages se trouve dans le premier répertoire répertorié dans la variable `PATH`. Vous pouvez le vérifier en exécutant la commande `echo $PATH` pour voir l'ordre actuel des répertoires dans lesquels les fichiers exécutables sont vérifiés sur votre système.
### Problème : le correctif échoue avec le message « Error unpacking rpm package… » (Erreur de décompactage du package rpm…)
**Problème** : une opération de correctif échoue avec un message d'erreur similaire au suivant :
```
Error : Error unpacking rpm package python-urllib3-1.25.9-1.amzn2.0.2.noarch
python-urllib3-1.25.9-1.amzn2.0.1.noarch was supposed to be removed but is not!
failed to run commands: exit status 1
```
**Cause 1** : lorsqu'un package particulier est présent dans plusieurs installateurs de packages, comme `pip` et `yum` ou `dnf`, des conflits peuvent survenir lors de l'utilisation du gestionnaire de packages par défaut.
Un exemple courant est celui du package `urllib3`, qui se trouve dans `pip`, `yum` et `dnf`.
**Cause 2** : le package `python-urllib3` est endommagé. Cela peut se produire si les fichiers du package ont été installés ou mis à jour par `pip` après que le package `rpm` ait été précédemment installé par `yum` ou `dnf`.
**Solution** : supprimez le package `python-urllib3` de pip en exécutant la commande `sudo pip uninstall urllib3`, en conservant le package uniquement dans le gestionnaire de package par défaut (`yum` ou `dnf`).
### Problème : le correctif échoue avec le message « Erreur côté service lors du chargement de l’inventaire »
**Problème** : lorsque vous exécutez le document `AWS-RunPatchBaseline`, vous recevez le message d’erreur suivant :
```
Encounter service side error when uploading the inventory
```
**Cause** : deux commandes servant à exécuter `AWS-RunPatchBaseline` s’exécutaient en même temps sur le même nœud géré. Cela crée une condition de concurrence lors de l’initialisation du client boto3 lors des opérations d’application de correctifs.
**Solution** : vérifiez qu'aucune association State Manager, tâche de fenêtre de maintenance ou autre configuration qui exécute `AWS-RunPatchBaseline` selon une planification ne cible le même nœud géré en même temps.
### Problème : le correctif échoue avec le message « Errors were encountered while downloading packages » (Des erreurs ont été rencontrées lors du téléchargement des packages)
**Problème** : pendant le correctif, vous recevez un message d'erreur similaire au suivant :
```
YumDownloadError: [u'Errors were encountered while downloading
packages.', u'libxml2-2.9.1-6.el7_9.6.x86_64: [Errno 5] [Errno 12]
Cannot allocate memory', u'libxslt-1.1.28-6.el7.x86_64: [Errno 5]
[Errno 12] Cannot allocate memory', u'libcroco-0.6.12-6.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory', u'openldap-2.4.44-25.el7_9.x86_64:
[Errno 5] [Errno 12] Cannot allocate memory',
```
**Cause** : cette erreur peut se produire lorsque la mémoire disponible sur un nœud géré est insuffisante.
**Solution** : configurez la mémoire d'échange ou mettez à niveau l'instance vers un type différent pour augmenter la prise en charge de la mémoire. Lancez ensuite une nouvelle opération de correctif.
### Problème : l'application des correctifs échoue en raison d'une erreur de mémoire insuffisante (OOM)
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, l'opération de correction échoue en raison d'une mémoire insuffisante sur le nœud géré. Des erreurs telles que`Cannot allocate memory`, `Killed` (provenant du logiciel Linux OOM Killer) peuvent s'afficher, ou l'opération peut échouer de façon inattendue. Cette erreur est plus susceptible de se produire sur les instances disposant de moins de 1 Go de RAM, mais elle peut également affecter les instances disposant de plus de mémoire lorsqu'un grand nombre de mises à jour sont disponibles.
**Cause** : Patch Manager exécute des opérations de correction à l'aide du gestionnaire de packages natif sur le nœud géré. La mémoire requise lors d'une opération d'application de correctifs dépend de plusieurs facteurs, notamment :
+ Le nombre de packages installés et de mises à jour disponibles sur le nœud géré.
+ Le gestionnaire de packages utilisé et ses caractéristiques de mémoire.
+ Autres processus exécutés sur le nœud géré au moment de l'opération d'application des correctifs.
Les nœuds gérés dotés d'un grand nombre de packages installés ou d'un grand nombre de mises à jour disponibles nécessitent davantage de mémoire lors des opérations d'application de correctifs. Lorsque la mémoire disponible est insuffisante, le processus d'application des correctifs échoue et se termine avec un message d'erreur. Le système d'exploitation peut également mettre fin au processus d'application des correctifs.
**Solution** : essayez une ou plusieurs des solutions suivantes :
+ Planifiez les opérations d'application de correctifs pendant les périodes de faible charge de travail sur le nœud géré, par exemple en utilisant des fenêtres de maintenance.
+ Mettez à niveau l'instance vers un type disposant de plus de mémoire.
+ Configurez la mémoire d'échange sur le nœud géré. Notez que sur les instances dont le débit EBS est limité, une utilisation intensive du swap peut entraîner une dégradation des performances.
+ Passez en revue et réduisez le nombre de processus exécutés sur le nœud géré pendant les opérations d'application de correctifs.
### Problème : le correctif échoue avec le message suivant : « The following signatures couldn't be verified because the public key is not available » (Les signatures suivantes n'ont pas pu être vérifiées, car la clé publique n'est pas disponible)
**Problème** : le correctif échoue sur Ubuntu Server avec une erreur similaire à la suivante :
```
02/17/2022 21:08:43 root [ERROR]: W:GPG error:
http://repo.mysql.com/apt/ubuntu bionic InRelease: The following
signatures couldn't be verified because the public key is not available:
NO_PUBKEY 467B942D3A79BD29, E:The repository ' http://repo.mysql.com/apt/ubuntu bionic
```
**Cause** : la clé GNU Privacy Guard (GPG) a expiré ou est manquante.
**Solution** : actualisez la clé GPG ou ajoutez-la de nouveau.
Par exemple, en utilisant l'erreur montrée précédemment, nous voyons que la clé `467B942D3A79BD29` est manquante et doit être ajoutée. Pour ce faire, exécutez l'une des commandes suivantes :
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --recv-keys 467B942D3A79BD29
```
```
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 467B942D3A79BD29
```
Ou, pour actualiser toutes les clés, exécutez la commande suivante :
```
sudo apt-key adv --keyserver hkps://keyserver.ubuntu.com --refresh-keys
```
Si l'erreur se reproduit, nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce qu'un correctif soit disponible, vous pouvez modifier le fichier `/etc/apt/sources.list` afin d'omettre le référentiel pendant le processus de correctif.
Pour ce faire, ouvrez le fichier `sources.list` pour le modifier, localisez la ligne relative au référentiel et insérez un caractère `#` au début de la ligne pour la mettre en commentaire. Ensuite, enregistrez et fermez le fichier.
### Problème : l'application de correctifs échoue avec un message « NoMoreMirrorsRepoError »
**Problème** : vous recevez une erreur similaire à la suivante :
```
NoMoreMirrorsRepoError: failure: repodata/repomd.xml from pgdg94: [Errno 256] No more mirrors to try.
```
**Cause** : il y a une erreur dans le référentiel source.
**Solution** : nous vous recommandons de signaler le problème à l'organisation qui gère le référentiel. Jusqu'à ce que l'erreur soit corrigée, vous pouvez désactiver le référentiel au niveau du système d'exploitation. Pour ce faire, exécutez la commande suivante en remplaçant la valeur pour *repo-name* par le nom de votre dépôt :
```
yum-config-manager --disable repo-name
```
Voici un exemple.
```
yum-config-manager --disable pgdg94
```
Après avoir exécuté cette commande, lancez une autre opération de correctif.
### Problème : le correctif échoue avec un message « Unable to download payload » (Impossible de télécharger la charge utile)
**Problème** : vous recevez une erreur similaire à la suivante :
```
Unable to download payload:
https://s3.dualstack.eu-west-1.amazonaws.com/aws-ssm-eu-west-1/patchbaselineoperations/linux/payloads/patch-baseline-operations-1.83.tar.gz.
failed to run commands: exit status 156
```
**Cause** : la configuration du nœud géré contient des erreurs ou est incomplète.
**Solution** : assurez-vous que le nœud géré est configuré avec les éléments suivants :
+ Règle TCP 443 sortante dans le groupe de sécurité.
+ Règle TCP 443 de sortie dans NACL.
+ Règle TCP 1024-65535 d'entrée dans NACL.
+ NAT/IGW dans la table de routage pour fournir une connectivité à un point de terminaison S3. Si l'instance n'a pas d'accès internet, fournissez-lui une connectivité avec le point de terminaison S3. Pour ce faire, ajoutez un point de terminaison de passerelle S3 dans le VPC et intégrez-le à la table de routage du nœud géré.
### Problème : le correctif échoue avec un message « install errors: dpkg: error: dpkg frontend is locked by another process » (erreurs d'installation : dpkg : erreur : dpkg frontend est bloqué par un autre processus)
**Problème** : le correctif échoue avec une erreur similaire à la suivante :
```
install errors: dpkg: error: dpkg frontend is locked by another process
failed to run commands: exit status 2
Failed to install package; install status Failed
```
**Cause** : le gestionnaire de packages exécute déjà un autre processus sur un nœud géré au niveau du système d'exploitation. Si cet autre processus prend beaucoup de temps à se terminer, l'opération de correctif Patch Manager peut prendre du temps et échouer.
**Solution** : une fois que l'autre processus utilisant le gestionnaire de packages est terminé, exécutez une nouvelle opération de correctif.
### Problème : le correctif sur Ubuntu Server échoue avec une erreur « dpkg was interrupted » (dpkg a été interrompu)
**Problème** : sur Ubuntu Server, le correctif échoue avec une erreur similaire à la suivante :
```
E: dpkg was interrupted, you must manually run
'dpkg --configure -a' to correct the problem.
```
**Cause** : un ou plusieurs packages sont mal configurés.
**Solution** : procédez comme suit :
1. Vérifiez quels sont les packages concernés et quels sont les problèmes liés à chaque package en exécutant les commandes suivantes, une à la fois :
```
sudo apt-get check
```
```
sudo dpkg -C
```
```
dpkg-query -W -f='${db:Status-Abbrev} ${binary:Package}\n' | grep -E ^.[^nci]
```
1. Corrigez les packages concernés en exécutant la commande suivante :
```
sudo dpkg --configure -a
```
1. Si la commande précédente n'a pas permis de résoudre complètement le problème, exécutez la commande suivante :
```
sudo apt --fix-broken install
```
### Problème : l'utilitaire du gestionnaire de packages ne peut pas résoudre la dépendance d'un package
**Problème** : le gestionnaire de packages natif du nœud géré ne parvient pas à résoudre une dépendance de package et le correctif échoue. L'exemple de message d'erreur suivant indique ce type d'échec sur un système d'exploitation qui utilise `yum` comme gestionnaire de packages.
```
09/22/2020 08:56:09 root [ERROR]: yum update failed with result code: 1,
message: [u'rpm-python-4.11.3-25.amzn2.0.3.x86_64 requires rpm = 4.11.3-25.amzn2.0.3',
u'awscli-1.18.107-1.amzn2.0.1.noarch requires python2-botocore = 1.17.31']
```
**Cause** : sur les systèmes d'exploitation Linux, Patch Manager utilise le gestionnaire de packages natif de l'ordinateur pour exécuter les opérations de correctif. telles que `yum`, `dnf`, `apt` et `zypper`. Les applications détectent, installent, mettent à jour ou suppriment automatiquement les packages dépendants selon les besoins. Cependant, dans certaines conditions, le gestionnaire de packages peut être dans l'incapacité de mener à bien une opération de dépendance, comme par exemple :
+ Plusieurs référentiels contradictoires sont configurés sur le système d'exploitation.
+ L'URL d'un référentiel distant est inaccessible en raison de problèmes liés au réseau.
+ Un package pour la mauvaise architecture est trouvé dans le référentiel.
**Solution** : le correctif peut échouer en raison d'un problème de dépendance pour une grande variété de raisons. Par conséquent, nous vous recommandons de nous contacter AWS Support pour obtenir de l'aide pour le dépannage.
### Problème : échecs liés aux dépendances de verrouillage du package Zypper sur les nœuds gérés SLES
**Problème** : lorsque vous exécutez `AWS-RunPatchBaseline` avec l’opération `Install` sur des instances SUSE Linux Enterprise Server, l’application de correctifs échoue en raison d’erreurs de vérification des dépendances liées au verrouillage des packages. Vous pourriez recevoir des messages d’erreur similaires au suivant :
```
Problem: mock-pkg-has-dependencies-0.2.0-21.adistro.noarch requires mock-pkg-standalone = 0.2.0, but this requirement cannot be provided
uninstallable providers: mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 1: remove lock to allow installation of mock-pkg-standalone-0.2.0-21.adistro.noarch[local-repo]
Solution 2: do not install mock-pkg-has-dependencies-0.2.0-21.adistro.noarch
Solution 3: break mock-pkg-has-dependencies-0.2.0-21.adistro.noarch by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/c] (c): c
```
Dans cet exemple, le package `mock-pkg-standalone` est verrouillé, ce que vous pouvez vérifier en exécutant `sudo zypper locks` et en recherchant ce nom de package dans la sortie.
Vous pourriez également voir des entrées de journal indiquant des échecs de vérification des dépendances :
```
Encountered a known exception in the CLI Invoker: CLIInvokerError(error_message='Dependency check failure during commit process', error_code='4')
```
**Note**
Ce problème se produit uniquement pendant les opérations `Install`. Les opérations `Scan` n’appliquent pas de verrous de package et ne sont pas affectées par les verrous existants. »
**Cause** : cette erreur se produit lorsque les verrous de package zypper empêchent l’installation ou la mise à jour de packages en raison de conflits de dépendances. Les verrous de package peuvent être présents pour plusieurs raisons :
+ **Verrous appliqués par le client** : vous ou votre administrateur système avez verrouillé manuellement les packages à l’aide de commandes zypper comme `zypper addlock`.
+ **Correctifs rejetés par Patch Manager** : Patch Manager applique automatiquement le verrouillage des packages lorsque vous spécifiez des packages dans la liste des **correctifs rejetés** de votre référentiel de correctifs afin d’empêcher leur installation.
+ **Verrouillages résiduels dus à des opérations interrompues** : dans de rares cas, si une opération d’application de correctif a été interrompue (par exemple à la suite d’un redémarrage du système) avant que Patch Manager puisse nettoyer les verrous temporaires, des verrous de package résiduels peuvent rester sur votre nœud géré.
**Solution** : pour résoudre les problèmes de verrouillage de package zypper, suivez ces étapes en fonction de la cause :
**Étape 1 : identifier les packages verrouillés**
Connectez-vous à votre nœud géré SLES et exécutez la commande suivante pour répertorier tous les packages actuellement verrouillés :
```
sudo zypper locks
```
**Étape 2 : déterminer la source des verrous**
+ Si les packages verrouillés sont ceux que vous avez intentionnellement verrouillés pour la stabilité du système, déterminez s’ils doivent rester verrouillés ou s’ils peuvent être temporairement déverrouillés pour l’application de correctifs.
+ Si les packages verrouillés correspondent aux entrées de la liste des **correctifs rejetés** de votre référentiel de correctifs, il s’agit probablement de verrouillages résiduels résultant d’une interruption d’opération d’application de correctif. Au cours des opérations normales, Patch Manager applique ces verrous temporairement et les supprime automatiquement une fois l’opération terminée. Vous pouvez soit supprimer les packages de la liste des packages rejetés, soit modifier les règles de votre référentiel de correctifs.
+ Si vous ne reconnaissez pas les packages verrouillés et qu’ils n’ont pas été verrouillés intentionnellement, il se peut qu’il s’agisse de verrous résiduels résultant d’une interruption d’une opération d’application de correctif précédente.
**Étape 3 : supprimer les verrous le cas échéant**
Pour supprimer des verrous de package spécifiques, utilisez la commande suivante :
```
sudo zypper removelock package-name
```
Pour supprimer tous les verrous de package (à utiliser avec prudence), exécutez :
```
sudo zypper cleanlocks
```
**Étape 4 : mettez à jour votre référentiel de correctifs (le cas échéant)**
Si les verrouillages ont été provoqués par le rejet de correctifs dans votre référentiel de correctifs :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Patch Manager**.
1. Choisissez l’onglet **Référentiels de correctifs**, puis choisissez votre référentiel de correctifs personnalisé.
1. Choisissez **Actions**, puis **Modifier le référentiel de correctifs**.
1. Dans la section **Correctifs rejetés**, passez en revue les packages répertoriés et supprimez ceux dont l’installation devrait être autorisée.
1. Sélectionnez **Enregistrer les modifications**.
**Étape 5 : réessayer l’opération d’application de correctif**
Après avoir supprimé les verrous problématiques et mis à jour votre référentiel de correctifs si nécessaire, réexécutez le document `AWS-RunPatchBaseline`.
**Note**
Lorsque Patch Manager applique des verrous aux correctifs rejetés pendant les opérations `Install`, il est conçu pour nettoyer ces verrous automatiquement une fois l’opération d’application de correctif terminée. Si ces verrous apparaissent lors de l’exécution de `sudo zypper locks`, cela indique qu’une opération d’application de correctif précédente a été interrompue avant que le nettoyage puisse avoir lieu. Toutefois, si une opération d’application de correctif est interrompue, un nettoyage manuel peut être nécessaire, comme décrit dans cette procédure.
**Prévention** : pour éviter de futurs conflits de verrouillage zypper :
+ Examinez attentivement la liste des correctifs rejetés de votre référentiel de correctifs pour vous assurer qu’elle inclut uniquement les packages que vous souhaitez réellement exclure.
+ Évitez de verrouiller manuellement les packages qui peuvent être nécessaires comme dépendances pour les mises à jour de sécurité.
+ Si vous devez verrouiller des packages manuellement, documentez les raisons de ce choix et vérifiez régulièrement les verrous.
+ Assurez-vous que les opérations d’application de correctifs se terminent correctement et ne sont pas interrompues par des redémarrages du système ou d’autres facteurs.
+ Surveillez les opérations d’application de correctifs jusqu’à leur fin et évitez de les interrompre en redémarrant le système ou en effectuant d’autres actions susceptibles d’empêcher le bon nettoyage des verrous temporaires.
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Erreurs lors de l'exécution de `AWS-RunPatchBaseline` sur Windows Server
**Topics**
+ [Problème : paires de produits family/product incompatibles](#patch-manager-troubleshooting-product-family-mismatch)
+ [Problème: `AWS-RunPatchBaseline` renvoie un `HRESULT` (Windows Server)](#patch-manager-troubleshooting-hresult)
+ [Problème : le nœud géré n'a pas accès au catalogue Windows Update ou à WSUS](#patch-manager-troubleshooting-instance-access)
+ [Problème : le PatchBaselineOperations PowerShell module n'est pas téléchargeable](#patch-manager-troubleshooting-module-not-downloadable)
+ [Problème : correctifs manquants](#patch-manager-troubleshooting-missing-patches)
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-windows-concurrent-lock)
### Problème : paires de produits family/product incompatibles
**Problèmes :** lorsque vous créez un référentiel de correctifs dans la console Systems Manager, vous spécifiez une famille de produits et un produit. Par exemple, vous pouvez choisir ce qui suit :
+ **Famille de produits** : `Office`
**Produit** : `Office 2016`
**Cause** : Si vous tentez de créer une ligne de base de correctifs avec une family/product paire de produits qui ne correspond pas, un message d'erreur s'affiche. Voici les cas où cette situation peut se présenter :
+ Vous avez sélectionné une paire famille de produits et produit valide, puis supprimé la sélection de la famille de produits.
+ Vous avez choisi un produit dans la sous-liste **Obsolete or mismatched options (Options obsolètes ou non assorties)** au lieu de la sous-liste **Available and matching options (Options disponibles et assorties)**.
Les éléments de la sous-liste des **options obsolètes ou incompatibles** du produit peuvent avoir été saisis par erreur via un SDK ou une commande AWS Command Line Interface ()AWS CLI. `create-patch-baseline` Cela peut signifier qu'une faute de frappe a été introduite ou qu'un produit a été attribué à la mauvaise famille de produits. Un produit apparaît également dans la sous-liste **Obsolete or mismatched options (Options obsolètes ou non assorties)** s'il a été spécifié pour un référentiel de correctifs précédente mais qu'aucun correctif n'est disponible à partir de Microsoft.
**Solution** : pour éviter ce problème dans la console, sélectionnez toujours des options des sous-listes **Currently available options (Options actuellement disponibles)**.
Vous pouvez également consulter les produits pour lesquels des correctifs sont disponibles à l'aide de la commande `[https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html](https://docs.aws.amazon.com/cli/latest/reference/ssm/describe-patch-properties.html)` dans l' AWS CLI ou de la commande d'API `[https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_DescribePatchProperties.html)`.
### Problème: `AWS-RunPatchBaseline` renvoie un `HRESULT` (Windows Server)
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when
attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80240437
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)..
(Windows updates)
11/22/2020 09:17:30 UTC | Info | Searching for Windows Updates.
11/22/2020 09:18:59 UTC | Error | Searching for updates resulted in error: Exception from HRESULT: 0x80240437
----------ERROR-------
failed to run commands: exit status 4294967295
```
**Cause** : ce résultat indique que le Windows Update natif n'a pas APIs pu exécuter les opérations de correction.
**Solution** : vérifiez le code `HResult` dans les rubriques suivantes sur microsoft.com afin d'identifier les étapes de résolution de cette erreur :
+ [Codes d'erreur Windows Update par composant](https://learn.microsoft.com/en-us/windows/deployment/update/windows-update-error-reference)
+ [Erreurs courantes et mesures d'atténuation pour Windows Update](https://learn.microsoft.com/en-us/troubleshoot/windows-client/deployment/common-windows-update-errors)
### Problème : le nœud géré n'a pas accès au catalogue Windows Update ou à WSUS
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
Extracting PatchBaselineOperations zip file contents to temporary folder.
Verifying SHA 256 of the PatchBaselineOperations PowerShell module files.
Successfully downloaded and installed the PatchBaselineOperations PowerShell module.
Patch Summary for
PatchGroup :
BaselineId :
Baseline : null
SnapshotId :
RebootOption : RebootIfNeeded
OwnerInformation :
OperationType : Scan
OperationStartTime : 1970-01-01T00:00:00.0000000Z
OperationEndTime : 1970-01-01T00:00:00.0000000Z
InstalledCount : -1
InstalledRejectedCount : -1
InstalledPendingRebootCount : -1
InstalledOtherCount : -1
FailedCount : -1
MissingCount : -1
NotApplicableCount : -1
UnreportedNotApplicableCount : -1
EC2AMAZ-VL3099P - PatchBaselineOperations Assessment Results - 2020-12-30T20:59:46.169
----------ERROR-------
Invoke-PatchBaselineOperation : Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String
searchCriteria)
At C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\3d2d4864-04b7-4316-84fe-eafff1ea58
e3\PatchWindows\_script.ps1:230 char:13
+ $response = Invoke-PatchBaselineOperation -Operation Install -Snapsho ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (Amazon.Patch.Ba...UpdateOperation:InstallWindowsUpdateOperation) [Inv
oke-PatchBaselineOperation], Exception
+ FullyQualifiedErrorId : Exception Level 1:
Error Message: Exception Details: An error occurred when attempting to search Windows Update.
Exception Level 1:
Error Message: Exception from HRESULT: 0x80072EE2
Stack Trace: at WUApiLib.IUpdateSearcher.Search(String criteria)
at Amazon.Patch.Baseline.Operations.PatchNow.Implementations.WindowsUpdateAgent.SearchForUpdates(String searc
---Error truncated----
```
**Cause** : cette erreur peut être liée aux composants Windows Update ou à un manque de connectivité au catalogue Windows Update ou aux WSUS (Windows Server Update Services).
**Solution** : vérifiez que le nœud géré est connecté au [catalogue Microsoft Update](https://www.catalog.update.microsoft.com/home.aspx) via une passerelle Internet, une passerelle NAT ou une instance NAT. Si vous utilisez WSUS, vérifiez que le nœud géré est connecté au serveur WSUS de votre environnement. Si la connectivité est disponible pour la destination prévue, vérifiez la documentation Microsoft pour trouver d'autres causes potentielles à `HResult 0x80072EE2`. Cela peut indiquer un problème au niveau du système d'exploitation.
### Problème : le PatchBaselineOperations PowerShell module n'est pas téléchargeable
**Problème :** vous avez reçu une erreur similaire à la suivante.
```
Preparing to download PatchBaselineOperations PowerShell module from S3.
Downloading PatchBaselineOperations PowerShell module from https://s3.aws-api-domain/path_to_module.zip to C:\Windows\TEMP\Amazon.PatchBaselineOperations-1.29.zip.
----------ERROR-------
C:\ProgramData\Amazon\SSM\InstanceData\i-02573cafcfEXAMPLE\document\orchestration\aaaaaaaa-bbbb-cccc-dddd-4f6ed6bd5514\
PatchWindows\_script.ps1 : An error occurred when executing PatchBaselineOperations: Unable to connect to the remote server
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,_script.ps1
failed to run commands: exit status 4294967295
```
**Solution** : vérifiez la connectivité du nœud géré et les autorisations d'accès à Amazon Simple Storage Service (Amazon S3). Le rôle du nœud géré Gestion des identités et des accès AWS (IAM) doit utiliser les autorisations minimales citées dans[SSM Agentcommunications avec des AWS compartiments S3 gérés](ssm-agent-technical-details.md#ssm-agent-minimum-s3-permissions). Le nœud doit communiquer avec le point de terminaison Amazon S3 via le point de terminaison de la passerelle Amazon S3, la passerelle NAT ou la passerelle Internet. Pour plus d'informations sur les exigences du point de terminaison VPC pour AWS Systems Manager SSM Agent (SSM Agent), consultez. [Renforcement de la sécurité des instances EC2 à l’aide des points de terminaison de VPC pour Systems Manager](setup-create-vpc.md)
### Problème : correctifs manquants
**Problème** : `AWS-RunPatchbaseline` s'est terminé avec succès, mais il manque certains correctifs.
Voici quelques causes courantes et leurs solutions.
**Cause 1** : le référentiel n'est pas en vigueur.
**Solution 1** : pour vérifier si la cause est bien liée à ce problème, procédez comme suit :
1. Ouvrez la AWS Systems Manager console à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le panneau de navigation, sélectionnez **Run Command**.
1. Sélectionnez l'onglet **Historique des commandes**, puis sélectionnez la commande dont vous souhaitez vérifier le référentiel.
1. Sélectionnez le nœud géré auquel il manque des correctifs.
1. Sélectionnez **Étape 1 - Sortie**, et recherchez la valeur `BaselineId`.
1. Vérifiez la [Configuration de référentiel de correctifs](patch-manager-predefined-and-custom-patch-baselines.md#patch-manager-baselines-custom) affectée, c'est-à-dire le système d'exploitation, le nom du produit, la classification et la sévérité associés au référentiel de correctifs.
1. Accédez au [Catalogue des mises à jour Microsoft](https://www.catalog.update.microsoft.com/home.aspx).
1. Recherchez dans l'article de la base de connaissances Microsoft (KB) IDs (par exemple, KB3216916).
1. Vérifiez que la valeur indiquée sous **Product (Produit)** correspond à celle de votre nœud géré, et sélectionnez le **Title (Titre)** correspondant. Une nouvelle fenêtre **Actualiser les détails** s'ouvre.
1. Sous l'onglet **Présentation**, la **classification** et la **sévérité du MSRC** doivent correspondre à la configuration du référentiel de correctifs que vous avez trouvée précédemment.
**Cause 2** : le correctif a été remplacé.
**Solution 2** : pour vérifier si cela est vrai, procédez comme suit.
1. Accédez au [Catalogue des mises à jour Microsoft](https://www.catalog.update.microsoft.com/home.aspx).
1. Recherchez dans l'article de la base de connaissances Microsoft (KB) IDs (par exemple, KB3216916).
1. Vérifiez que la valeur indiquée sous **Product (Produit)** correspond à celle de votre nœud géré, et sélectionnez le **Title (Titre)** correspondant. Une nouvelle fenêtre **Actualiser les détails** s'ouvre.
1. Accédez à l'onglet **Détails du package**. Recherchez une entrée sous l'en-tête **Cette mise à jour a été remplacée par les mises à jour suivantes : **.
**Cause 3** : le même correctif peut avoir différents numéros de KB car les mises à jour en ligne des WSUS et de Window sont gérées comme des canaux de publication indépendants par Microsoft.
**Solution 3** : vérifiez l'éligibilité du correctif. Si le package n'est pas disponible sous les WSUS, installez la [version 14393.3115 du système d'exploitation](https://support.microsoft.com/en-us/topic/july-16-2019-kb4507459-os-build-14393-3115-511a3df6-c07e-14e3-dc95-b9898a7a7a57). Si le package est disponible pour toutes les versions du système d'exploitation, installez les [versions de système d'exploitation 18362.1256 et 18363.1256](https://support.microsoft.com/en-us/topic/december-8-2020-kb4592449-os-builds-18362-1256-and-18363-1256-c448f3df-a5f1-1d55-aa31-0e1cf7a440a9).
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
Cannot acquire lock on C:\ProgramData\Amazon\SSM\patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Erreurs lors de l'exécution `AWS-RunPatchBaseline` sur macOS
**Topics**
+ [Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.](#patch-manager-troubleshooting-macos-concurrent-lock)
### Problème : Impossible d'acquérir le verrou. Une autre opération de correction est en cours.
**Problème** : lors de l'exécution`AWS-RunPatchBaseline`, le correctif échoue avec le code d'erreur 4 et le message d'erreur suivant.
```
[ERROR]: Cannot acquire lock on /var/log/amazon/ssm/patch-baseline-concurrent.lock. Another patching operation is in progress.
```
**Cause** : Cette erreur se produit lorsque plusieurs opérations d'application de correctifs tentent de s'exécuter simultanément sur le même nœud géré. Le fichier de verrouillage empêche les opérations de correction simultanées afin d'éviter les conflits et de garantir la stabilité du système.
**Solution** : Assurez-vous que les opérations d'application de correctifs ne sont pas planifiées pour s'exécuter simultanément sur le même nœud géré. Passez en revue les configurations suivantes pour identifier et résoudre les conflits de planification :
+ **Politiques de correctifs** : vérifiez les configurations de vos politiques de correctifs de configuration rapide pour vous assurer qu'elles ne se chevauchent pas avec d'autres programmes de correctifs.
+ **Fenêtres de maintenance** : passez en revue vos associations de fenêtres de maintenance pour vérifier que plusieurs fenêtres ne ciblent pas les mêmes nœuds gérés avec des tâches d'application de correctifs à des moments qui se chevauchent.
+ Opérations **manuelles de correction immédiate** : évitez de lancer des opérations manuelles de **correction immédiate** pendant que l'application de correctifs planifiée est en cours.
## Utilisation des AWS Support runbooks d'automatisation
AWS Support fournit deux runbooks d'automatisation que vous pouvez utiliser pour résoudre certains problèmes liés à l'application de correctifs.
+ `AWSSupport-TroubleshootWindowsUpdate` : le dossier d’exploitation [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/awssupport-troubleshoot-windows-update.html) est utilisé pour identifier les problèmes susceptibles de faire échouer les mises à jour Windows Server des instances Amazon Elastic Compute Cloud (Amazon EC2) Windows Server.
+ `AWSSupport-TroubleshootPatchManagerLinux` : le dossier d’exploitation [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-troubleshoot-patch-manager-linux.html) résout les problèmes courants susceptibles de provoquer l’échec d’un correctif sur les nœuds gérés basés sur Linux avec Patch Manager. L’objectif principal de ce dossier d’exploitation est d’identifier la cause première de l’échec de la commande de correctif et de suggérer un plan de correction.
**Note**
L’utilisation des dossiers d’exploitation Automation est payante. Pour plus d’informations, consultez la section [Tarification AWS Systems Manager pour Automation](https://aws.amazon.com/systems-manager/pricing/#Automation).
## En contactant AWS Support
Si vous ne trouvez pas de solutions de dépannage dans cette section ou dans les problèmes Systems Manager de [AWS re:Post](https://repost.aws/tags/TA-UbbRGVYRWCDaCvae6itYg/aws-systems-manager), et que vous disposez d'une [formule Support Développeur, Business ou Entreprise](https://aws.amazon.com/premiumsupport/plans), vous pouvez formuler une demande de prise en charge technique à l'adresse [AWS Support](https://aws.amazon.com/premiumsupport/).
Avant de nous contacter Support, collectez les objets suivants :
+ [Journaux SSM Agent](ssm-agent-logs.md)
+ Run CommandID de commande, ID de fenêtre de maintenance ou ID d'exécution d'Automation
+ Pour les nœuds gérés Windows Server, munissez-vous également les éléments suivants :
+ `%PROGRAMDATA%\Amazon\PatchBaselineOperations\Logs` tels qu'ils figurent sous l'onglet **Windows** de [Installation des correctifs](patch-manager-installing-patches.md)
+ Journaux de mise à jour Windows : pour Windows Server 2012 R2 et versions antérieures, utilisez `%windir%/WindowsUpdate.log`. Pour Windows Server 2016 et les versions ultérieures, exécutez d'abord la PowerShell commande [https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps](https://docs.microsoft.com/en-us/powershell/module/windowsupdate/get-windowsupdatelog?view=win10-ps)avant d'utiliser `%windir%/WindowsUpdate.log`
+ Pour les nœuds gérés Linux, munissez-vous également les éléments suivants :
+ Le contenu du répertoire `/var/lib/amazon/ssm/instance-id/document/orchestration/Run-Command-execution-id/awsrunShellScript/PatchLinux`.