Dépannage

Cette page vous explique comment résoudre les problèmes liés à Batch.

Si vous essayez de résoudre un problème lié à une tâche pour laquelle vous ne disposez d'aucun message d'erreur, vérifiez si l'historique de la tâche contient des messages d'erreur en affichant les événements d'état avant de consulter ce document.

Pour en savoir plus sur le dépannage d'une tâche, consultez également documents:

• Problèmes connus
• Analyser une tâche à l'aide des journaux
• Consulter les journaux d'audit

Erreurs de création de tâches

Si vous ne parvenez pas à créer un job, cela peut être dû à l'une des erreurs présentées dans cette section.

Quota insuffisant

Problème

L'un des problèmes suivants se produit lorsque vous essayez de créer une tâche :

• Lorsque la tâche est à l'état QUEUED, le problème suivant s'affiche dans le champ statusEvents :

  Quota checking process decides to delay scheduling for the job JOB_UID due to inadequate quotas [Quota: QUOTA_NAME, limit: QUOTA_LIMIT, usage: QUOTA_CURRENT_USAGE, wanted: WANTED_QUOTA.].
  

  Ce problème indique que la tâche a été retardée en raison du utilisation actuelle (QUOTA_USAGE) et limite (QUOTA_LIMIT) d'un quota de QUOTA_NAME a empêché l'accès utilisation demandée (WANT_QUOTA).

• Lorsque la tâche est dans l'un des états QUEUED, SCHEDULED ou FAILED, l'un des problèmes suivants s'affiche dans le champ statusEvents :

  RESOURCE_NAME creation failed:
  Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in region REGION
  

  RESOURCE_NAME creation failed:
  Quota QUOTA_NAME exceeded. Limit: QUOTA_LIMIT in zone ZONE
  

  Ce problème indique que la création d'une ressource a échoué, car la requête a dépassé votre quota QUOTA_NAME, qui est limité à QUOTA_LIMIT à l'emplacement spécifié.

Solution

Pour identifier le problème, procédez comme suit :

• Si la tâche a été retardée, essayez d'attendre qu'un quota supplémentaire soit libéré.

• Si la tâche a échoué en raison d'un quota insuffisant ou si ces retards persistent, essayez d'éviter un quota insuffisant en procédant comme suit :

  • Créez des tâches qui utilisent moins de ce quota ou un autre quota. Par exemple, spécifiez un autre emplacement ou type de ressource autorisé pour ou répartir l'utilisation du quota entre plusieurs projets.

  • Demandez à Google Cloud d'augmenter la limite de quota de votre projet.

Pour en savoir plus, consultez Quotas et limites par lot Utiliser des quotas

Autorisations insuffisantes pour agir en tant que compte de service

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche :

• Si la tâche n'utilise pas de modèle d'instance, le problème se présente comme suit :

  caller does not have access to act as the specified service account: SERVICE_ACCOUNT_NAME
  

• Si la tâche utilise un modèle d'instance, le problème se présente comme suit :

  Error: code - CODE_SERVICE_ACCOUNT_MISMATCH, description - The service account specified in the instance template INSTANCE_TEMPLATE_SERVICE_ACCOUNT doesn't match the service account specified in the job JOB_SERVICE_ACCOUNT for JOB_UID, project PROJECT_NUMBER
  

Ce problème se produit généralement parce que l'utilisateur qui crée le job n'a pas des autorisations suffisantes pour agir en tant que compte de service utilisé par le job, qui est contrôlé par Autorisation iam.serviceAccounts.actAs.

Solution

Pour identifier le problème, procédez comme suit :

1. Si le job utilise un modèle d'instance, vérifiez que le compte de service spécifié dans le modèle d'instance correspond au compte de service spécifié dans la définition du job.
2. Assurez-vous que l'utilisateur qui crée le job a été attribué au rôle Utilisateur du compte de service (roles/iam.serviceAccountUser) sur le compte de service spécifié pour le job. Pour en savoir plus, consultez Gérer l'accès
3. Recréez la tâche.

Réseaux répétés

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche :

Networks must be distinct for NICs in the same InstanceTemplate

Ce problème est dû au fait que vous avez spécifié le réseau pour une tâche plusieurs fois.

Solution

Pour résoudre le problème, recréez le job et spécifiez le réseau à l'aide de la commande l'une des options suivantes:

• Modèle d'instance de VM : si vous souhaitez utiliser un modèle d'instance de VM lors de la création de cette tâche, vous devez spécifier le réseau dans le modèle d'instance de VM.
• Champs network et subnetwork: Ces champs peuvent être utilisés dans le corps de la requête lorsque vous créez une tâche à l'aide de la propriété Batch ou dans le fichier de configuration JSON lorsque vous créez à l'aide de la gcloud CLI.
• Options --network et --subnetwork : ces options peuvent être utilisées avec la commande gcloud batch jobs submit lorsque vous créez une tâche à l'aide de la CLI gcloud.

Pour en savoir plus, consultez Spécifiez le réseau pour une tâche.

Réseau non valide pour VPC Service Controls

Problème

Le problème suivant se produit lorsque vous essayez de créer une tâche :

no_external_ip_address field is invalid. VPC Service Controls is enabled for the project, so external ip address must be disabled for the job. Please set no_external_ip_address field to be true

Solution

Ce problème survient lorsque vous essayez de créer et d'exécuter un job avec des VM disposant d'adresses IP externes appartenant à un périmètre de service VPC Service Controls.

Pour résoudre le problème, créez une tâche qui bloque l'accès externe pour toutes les VM.

Pour en savoir plus sur la configuration de la mise en réseau pour un job dans un le périmètre de service VPC Service Controls, consultez la page Utiliser VPC Service Controls avec Batch.

Problèmes liés aux jobs et erreurs d'échec

Si vous rencontrez des problèmes avec un job qui ne s'exécute pas correctement ou qui échoue pour des raisons peu claires, cela peut être dû à l'une des erreurs de cette section ou à l'un des codes de sortie de la section Codes de sortie en cas d'échec de la tâche suivante.

Aucun journal dans Cloud Logging

Problème

Vous devez déboguer un job, mais aucun journal ne s'affiche pour celui-ci dans Cloud Logging.

Ce problème survient souvent pour les raisons suivantes:

• L'API Cloud Logging n'est pas activée pour votre projet. Même si vous configurez correctement tout le reste pour les journaux d'une tâche, elle ne produira pas de journaux si le service n'est pas activé pour votre projet.
• Le compte de service de la tâche n'est pas autorisé à écrire des journaux. Un job ne peut pas générer de journaux sans autorisations suffisantes.
• Le job n'a pas été configuré pour générer des journaux. Pour générer des journaux dans Cloud Logging, Cloud Logging doit être activé pour un job. Les exécutables de la tâche doivent également être configurés pour écrire toutes les informations que vous souhaitez afficher dans les journaux dans les flux de sortie standard (stdout) et d'erreur standard (stderr). Pour en savoir plus, consultez la section Analyser une tâche à l'aide des journaux.
• Les tâches n'ont pas été exécutées. Les journaux ne peuvent pas être générés tant que des ressources n'ont pas été attribuées aux tâches et que celles-ci ne commencent pas à s'exécuter.
• Cloud Logging a été configuré pour exclure automatiquement les journaux de la tâche. Les journaux des jobs Batch ne peuvent pas s'afficher si vous avez configuré Filtres d'exclusion pour Cloud Logging entraînant l'exclusion des journaux des jobs Batch.

Solution

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

1. Assurez-vous que les journaux n'ont pas été automatiquement exclus de Cloud Logging en désactivant filtres d'exclusion pour Cloud Logging.
2. Assurez-vous que l'API Cloud Logging est activée pour votre projet.
3. Assurez-vous que le compte de service de la tâche dispose du rôle IAM Rédacteur de journaux (roles/logging.logWriter). Pour en savoir plus, consultez Activez Batch pour un projet.
4. Affichez les détails de la tâche à l'aide de gcloud CLI ou de l'API Batch. Les détails de l'offre peuvent vous aider à comprendre pourquoi l'emploi n'a pas été trouvé génèrent des journaux et peuvent fournir les informations dont vous espériez obtenir à partir des journaux. Par exemple, procédez comme suit :
   1. Pour vérifier que la journalisation est activée, examinez le champ logsPolicy de la tâche.
   2. Pour vérifier que l'exécution de la tâche s'est bien terminée, consultez les Champ status.

Après avoir apporté des modifications, recréez le job et attendez qu'il soit avant de vérifier les journaux.

Aucun rapport sur l'agent de service

Problème

Le problème suivant apparaît dans la Champ statusEvents pour un job qui ne s'exécute pas correctement ou qui a échoué avant la création des VM:

No VM has agent reporting correctly within time window NUMBER_OF_SECONDS seconds, VM state for instance VM_NAME is TIMESTAMP,agent,start

Le problème indique qu'aucune VM d'un job ne transmet de rapport au Agent de service Batch.

Ce problème survient souvent pour les raisons suivantes:

• Les VM de la tâche ne disposent pas des autorisations nécessaires. Les VM d'une tâche nécessitent des autorisations spécifiques pour signaler leur état à l'agent de service de traitement par lot. Vous pouvez fournir ces autorisations pour les VM d'un job en accordant Rôle Responsable du signalement de l'agent Batch (roles/batch.agentReporter) au compte de service de la tâche.
• Les VM de la tâche rencontrent des problèmes de réseau. Les VM d'une tâche nécessitent un accès réseau pour communiquer avec l'agent de service de traitement par lot.
• Les VM du job utilisent une image d'OS de VM par lot obsolète ou utilisent une image d'OS de VM avec un logiciel d'agent de service Batch obsolète. Les VM du job nécessitent un logiciel dans leur image d'OS de VM qui fournit le les dépendances actuelles afin de créer des rapports Agent de service Batch.

Solution

Pour identifier le problème, procédez comme suit :

1. Vérifiez que les VM de la tâche disposent des autorisations requises pour signaler leur état à l'agent de service de traitement par lot.

   1. Pour identifier le compte de service du job, Affichez les détails de la tâche à l'aide de gcloud CLI ou de l'API Batch. Si aucun compte de service n'est répertorié, le job utilise l'instance Compute Engine le compte de service par défaut.

   2. Vérifiez que le compte de service du job dispose des autorisations nécessaires Rôle de responsable du signalement de l'agent Batch (roles/batch.agentReporter). Pour en savoir plus, consultez Gérer l'accès et Restreindre l'utilisation des comptes de service.

      Par exemple, pour accorder au compte de service Compute Engine par défaut les autorisations requises, exécutez la commande suivante:

      gcloud projects add-iam-policy-binding PROJECT_ID \
        --role roles/batch.agentReporter \
        --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com
      

      • Remplacez PROJECT_NUMBER par votre numéro de projet.
      • Remplacez PROJECT_ID par votre ID de projet.

2. Vérifiez que les VM de la tâche disposent d'un accès réseau approprié. Pour en savoir plus, consultez Présentation de la mise en réseau par lot Résolvez les problèmes réseau courants.

3. Si vous avez spécifié l'image du système d'exploitation de la VM pour la tâche, vérifiez qu'elle est actuellement compatible.

   1. Si vous avez activé Cloud Logging pour ce job, vous pouvez et identifiez ce problème en vérifiant les éléments suivants : journaux de l'agent (batch_agent_logs). Pour en savoir plus, consultez Analyser un job à l'aide des journaux

      • Journal pour l'erreur de logiciel de l'agent de service Batch obsolète :

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_AGENT_VERSION: outdated Batch agent version used.
        

        BATCH_AGENT_VERSION est la version logicielle pour avec l'agent de service Batch (par exemple, cloud-batch-agent_20221103.00_p00).

      • Journal de l'erreur d'image de l'OS de la VM de traitement par lot obsolète :

        rpc error: code = FailedPrecondition, desc = Invalid resource state for BATCH_VM_OS_IMAGE_NAME: outdated Batch image version.
        

        Le BATCH_VM_OS_IMAGE_NAME est la version spécifique d'un Image de VM de l'OS issue de Batch et utilisée par le job (par exemple, batch-debian-11-20220909-00-p00)

   2. Vous pouvez résoudre ce problème en utilisant une image d'OS de VM plus récente. Si le job utilise une image personnalisée, recréez l'image personnalisée en fonction de la dernière version d'une image publique compatible.

      Pour en savoir plus, consultez la page Images d'OS de VM compatibles. et afficher les images d'OS des VM.

4. Recréez la tâche.

Métriques de ressources manquantes dans Cloud Monitoring

Problème

Vous souhaitez Afficher les métriques sur les ressources d'une tâche mais il manque une partie ou la totalité des métriques attendues.

Ce problème survient souvent pour les raisons suivantes:

• L'API n'était pas activée pour votre projet. Même si vous configurez correctement tout le reste dans votre projet, les ressources Les métriques peuvent ne pas s'afficher tant que l'API Cloud Monitoring n'est pas activée. Pour l'agent Ops, vous devez également activer l'API Cloud Logging.
• Vous ne disposez pas des autorisations nécessaires pour afficher les métriques. Vous ne pouvez pas consulter les métriques sans autorisations suffisantes.
• Les VM du job ne se sont pas exécutées. Les métriques ne peuvent pas être générées pour une tâche tant qu'au moins une des VM de la tâche n'est pas en cours d'exécution.
• La configuration ou les autorisations de la tâche n'étaient pas compatibles avec les métriques de l'agent Ops. Certaines métriques de ressources ne peuvent être fournies que par l'agent Ops. Pour faciliter les opérations d'agent : un job doit répondre aux exigences de l'agent Ops, installer l'agent Ops et utiliser un compte de service capable d'écrire des métriques Surveillance.
• Vous devez utiliser une autre méthode ou un autre filtre pour afficher les métriques. Certaines méthodes d'affichage des métriques n'affichent pas les métriques pour les VM après que celles-ci sont supprimés. De plus, les métriques ne s'affichent pas si elles sont omises par les filtres ou la période affichée. De plus, les graphiques de métriques disposent qui peuvent rendre les petites quantités de données trop fines pour être affichées.
• Les métriques ont été supprimées. Vous ne pouvez pas consulter les métriques après leur suppression. qui intervient automatiquement après la période de conservation périodes.

Solution

Si seules les métriques de l'agent Ops sont manquantes, essayez d'abord de résoudre le problème en procédant comme suit :

1. Vérifiez la configuration de la tâche en procédant comme suit :
   1. Pour afficher les informations de configuration complètes de la tâche, consultez les détails de la tâche à l'aide de la gcloud CLI ou de l'API Batch. Utiliser la sortie pour les étapes restantes.
   2. Assurez-vous que le compte de service de la tâche dispose des autorisations nécessaires pour écrire des métriques Ops Agent.
   3. Assurez-vous que le job respecte toutes les Conditions requises pour l'Agent Ops
   4. Assurez-vous que la tâche installe correctement l'agent Ops. Bien qu'il soit possible d'installer manuellement l'agent Ops dans un exécutable, la méthode recommandée consiste à installer automatiquement l'agent Ops en définissant le champ installOpsAgent sur true.
2. Si le problème persiste, consultez la page Résoudre les problèmes liés à l'agent Ops dans la documentation Google Cloud Observability.

Sinon, résolvez le problème en procédant comme suit:

1. Assurez-vous que l'API Monitoring est activée pour votre projet:

   Enable the API

2. Assurez-vous que les VM du job ont commencé à s'exécuter et que l'exécution est toujours dans la Surveiller les durées de conservation Vous pouvez consulter la durée d'exécution de la tâche en affichant les détails de la tâche.
3. Vérifiez que les méthodes que vous utilisez pour l'affichage ne présentent aucun problème en procédant comme suit:
   1. À moins que vous ne souhaitiez afficher les métriques des ressources en cours d'exécution uniquement, assurez-vous que vous consultez les métriques à l'aide de l'Explorateur de métriques ou d'un créé à partir de graphiques de l'explorateur de métriques. D'autres méthodes, telles que les tableaux de bord Compute Engine, n'affichent pas les métriques des ressources supprimées.
   2. Assurez-vous que la période d'affichage inclut la durée d'exécution de la tâche. Pour les graphiques, assurez-vous également que le résolution du graphique est approprié pour vos données.
   3. Assurez-vous de n'avoir filtres qui masquent les données.
4. Si le problème persiste, consultez la Résoudre les problèmes liés à Cloud Monitoring dans la documentation Google Cloud Observability.

Contrainte non respectée pour les adresses IP externes de VM

Problème

Le problème suivant apparaît dans la Champ statusEvents pour une tâche ayant échoué:

Instance VM_NAME creation failed: Constraint constraints/compute.vmExternalIpAccess violated for project PROJECT_NUMBER.
Add instance VM_NAME to the constraint to use external IP with it.

Ce problème survient, car votre projet, votre dossier ou votre organisation a défini la contrainte de règle d'administration compute.vmExternalIpAccess afin que seules les VM de la liste d'autorisation puissent utiliser des adresses IP externes.

Solution

Pour résoudre le problème, recréez le job et effectuez l'une des opérations suivantes:

• Utilisez un projet exempté de la contrainte.
• Créez une tâche qui bloque l'accès externe pour toutes les VM.

Contrainte non respectée pour les images de confiance

Problème

Le problème suivant apparaît dans la Champ statusEvents pour une tâche ayant échoué:

Instance VM_NAME creation failed: Constraint constraints/compute.trustedImageProjects violated for project PROJECT_ID. Use of images from project batch-custom-image is prohibited.

Solution

Ce problème se produit, car votre projet a défini la contrainte de règles sur les images de confiance (compute.trustedImageProjects) afin que les images de Batch, qui se trouvent dans le projet d'images batch-custom-image, ne soient pas autorisées.

Pour résoudre le problème, effectuez au moins l'une des opérations suivantes:

• Recréez la tâche pour spécifier une image d'OS de VM déjà autorisée par la contrainte du règlement relatif aux images de confiance.
• Demandez à votre administrateur d'autoriser la modification du de règle relative aux images de confiance pour autoriser les images d'OS de VM à partir du Projet d'images batch-custom-image. Pour obtenir des instructions, consultez la section Contrôler l'accès aux images de l'OS de la VM pour Batch.

Échec du job lors de l'utilisation d'un modèle d'instance

Problème

Le problème suivant s'affiche dans le champ statusEvents pour une tâche ayant échoué qui utilise un modèle d'instance :

INVALID_FIELD_VALUE,BACKEND_ERROR

Ce problème est dû à des problèmes peu clairs avec le modèle d'instance du job.

Solution

Pour déboguer le problème, procédez comme suit:

1. Créer un MIG à l'aide du modèle d'instance et observez si des erreurs se produisent avec plus de détails.

2. Facultatif: Pour essayer de trouver plus d'informations, consultez la opération de longue durée qui crée le MIG dans la console Google Cloud.

   Accéder à "Opérations Compute Engine"

Codes de sortie en cas d'échec de la tâche

Lorsqu'une tâche spécifique d'une tâche échoue, elle renvoie un code de sortie non nul. Selon la configuration du champ ignoreExitStatus, une tâche ayant échoué peut ou non entraîner l'échec d'une tâche.

En plus de tous les codes de sortie que vous définissez dans un exécutable, Batch inclut plusieurs codes de sortie réservés, y compris les les codes de sortie suivants.

Préemption de VM (50001)

Problème

Le problème suivant apparaît dans la Champ statusEvents pour un emploi:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Spot Preemption with exit code 50001.

Ce problème survient lorsqu'une VM Spot pour la tâche est préemptée au moment de l'exécution.

Solution

Pour résoudre le problème, effectuez l'une des opérations suivantes:

• Relancez la tâche en utilisant de nouvelles tentatives automatisées ou réexécuter manuellement le job.
• Pour vous assurer qu'il n'y a pas de préemption, utilisez plutôt des VM avec le modèle de provisionnement standard.

Délai avant expiration de la création de rapports sur les VM (50002)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche :

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to Batch no longer receives VM updates with exit code 50002.

Ce problème se produit lorsqu'un délai avant expiration dans le backend empêche Batch de recevoir des mises à jour d'une VM pour la tâche. Malheureusement, de nombreuses défaillances matérielles ou logicielles peuvent entraîner ne répondent pas (par exemple, une VM peut planter en raison d'un hôte temporaire) ; un événement ou des ressources insuffisantes.

Solution

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

1. Si le problème est temporaire et qu'il se résout de lui-même, vous pouvez relancer la tâche à l'aide de tentatives automatisées ou manuelles et d'exécuter à nouveau le job.

2. Si le problème persiste, identifiez et corrigez la cause du problème ne répond pas en effectuant une ou plusieurs des actions suivantes:

   • Recommandation : Obtenez de l'aide auprès de l'assistance Google Cloud ou du libellé de lot sur les forums Cloud.

   • Essayez d'identifier et de résoudre le problème vous-même. Par exemple, si vous familiarisé avec Compute Engine, vous pouvez essayer de résoudre VM du job en procédant comme suit:

     1. Pour identifier les noms des VM de votre tâche, procédez comme suit :

        1. Affichez les journaux de la tâche.
        2. Filtrez les journaux pour afficher les entrées contenant la phrase report agent state:.

        3. Examinez les journaux pour déterminer la VM pour chaque tentative de chaque tâche. Chaque journal est semblable à ce qui suit, dans lequel il y a une expression instance: et une ou plusieurs expressions task_id:.

           report agent state: ... instance:"INSTANCE_NAME" ... task_id:"task/JOB_UID-group0-TASK_INDEX/TASK_RETRIES/0 ..."
           

           Ce journal inclut les valeurs suivantes:

           • INSTANCE_NAME : nom de la VM.
           • JOB_UID : ID unique (UID) de la tâche.
           • TASK_INDEX : index de la tâche.
           • TASK_RETRIES: tentative de la tâche. exécutée sur cette VM, formatée comme le nombre de tentatives. Par exemple, cette valeur est 0 pour la première tentative d'une tâche. Chaque tâche n'est tentée qu'une seule fois, sauf si vous activez les nouvelles tentatives automatiques des tâches.

     2. Résolvez les problèmes liés aux VM de votre tâche à l'aide de la documentation Compute Engine. Par exemple, consultez les articles Résoudre les problèmes liés aux arrêts et aux redémarrages de VM et Dépannage du démarrage des VM.

La VM a redémarré pendant l'exécution (50003)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche :

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is rebooted during task execution with exit code 50003.

Ce problème se produit lorsqu'une VM associée à un job redémarre de manière inattendue pendant l'exécution.

Solution

Pour résoudre ce problème, réessayez la tâche à l'aide des nouvelles tentatives de tâche automatisées ou en réexécutant manuellement le job.

La VM et la tâche ne répondent pas (50004)

Problème

Le problème suivant s'affiche dans le champ statusEvents d'une tâche :

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to tasks cannot be canceled with exit code 50004.

Ce problème se produit lorsqu'une tâche atteint la limite de temps sans réponse et ne peut pas être annulée.

Solution

Pour résoudre ce problème, réessayez la tâche à l'aide des nouvelles tentatives de tâche automatisées ou en réexécutant manuellement le job.

La tâche s'exécute sur la durée d'exécution maximale (50005)

Problème

Le problème suivant apparaît dans la Champ statusEvents pour un emploi:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to task runs over the maximum runtime with exit code 50005.

Ce problème survient dans les cas suivants:

• La durée d'exécution d'une tâche dépasse la limite de temps spécifiée dans le champ maxRunDuration.
• Le temps d'exécution d'un exécutable dépasse la limite de temps spécifiée dans le champ timeout.

Pour identifier précisément la limite de temps dépassée, affichez les journaux de la tâche et recherchez un journal qui mentionne le code de sortie 50005. Ce champ "textPayload" de ce journal indique où et quand la limite de temps a été dépassée.

Solution

Pour résoudre le problème, vérifiez la durée d'exécution totale requise la tâche ou l'exécutable qui a dépassé la limite de temps. Effectuez l'une des opérations suivantes :

• Si vous ne vous attendez à cette erreur que de temps en temps, par exemple pour une tâche ou un exécutable avec un temps d'exécution incohérent, vous pouvez essayer de recréer la tâche et de la configurer pour automatiser les tentatives d'exécution des tâches afin d'essayer d'augmenter le taux de réussite.

• Sinon, si la tâche ou l'exécutable a besoin de plus de temps pour terminer son exécution que le délai avant expiration actuel, définissez un délai avant expiration plus long.

VM recréée pendant l'exécution (50006)

Problème

Le problème suivant apparaît dans la Champ statusEvents pour un emploi:

Task state is updated from PRE-STATE to FAILED on zones/ZONE/instances/INSTANCE_ID due to VM is recreated during task execution with exit code 50006.

Ce problème se produit lorsqu'une VM pour une tâche est recréée de manière inattendue au moment de l'exécution.

Solution

Pour résoudre ce problème, relancez la tâche en utilisant de nouvelles tentatives automatisées ou réexécuter manuellement le job.

Étape suivante

• Obtenir de l'aide pour Batch