web-dev-qa-db-fra.com

Les codes de sortie et les états de sortie signifient-ils quelque chose d'étincelant?

Je vois des codes de sortie et des statuts de sortie tout le temps lorsque je lance spark on yarn:

Voici quelques-uns:

  • CoarseGrainedExecutorBackend: RECEIVED SIGNAL 15: SIGTERM

  • ...failed 2 times due to AM Container for application_1431523563856_0001_000002 exited with exitCode: 10...

  • ...Exit status: 143. Diagnostics: Container killed on request

  • ...Container exited with a non-zero exit code 52:...

  • ...Container killed on request. Exit code is 137...

Je n'ai jamais trouvé aucun de ces messages utile ... Y a-t-il une chance d'interpréter ce qui ne va vraiment pas avec ces messages? J'ai cherché haut et bas un tableau expliquant les erreurs mais rien.

Le SEUL que je peux déchiffrer de ceux ci-dessus est le code de sortie 52, mais c'est parce que j'ai regardé le code source ici . C'est dire que c'est un MOO.

Dois-je arrêter d'essayer d'interpréter le reste de ces codes de sortie et états de sortie? Ou est-ce que je manque d'une manière évidente que ces chiffres signifient réellement quelque chose?

Même si quelqu'un pouvait me dire la différence entre exit code, exit status et SIGNAL qui seraient utiles. Mais je suis juste en train de deviner au hasard en ce moment, et il semble que tout le monde autour de moi qui utilise spark l'est aussi).

Et, enfin, pourquoi certains des codes de sortie sont-ils inférieurs à zéro et comment les interpréter?

Par exemple. Exit status: -100. Diagnostics: Container released on a *lost* node

20
Sother

Ni les codes de sortie, ni l'état, ni les signaux ne sont Spark spécifiques mais font partie du fonctionnement des processus sur des systèmes de type Unix.

Statut de sortie et code de sortie

Le statut de sortie et les codes de sortie sont des noms différents pour la même chose. Un état de sortie est un nombre compris entre 0 et 255 qui indique le résultat d'un processus après sa fin. Le statut de sortie 0 indique généralement le succès. La signification des autres codes dépend du programme et doit être décrite dans la documentation du programme. Il existe cependant des codes standard établis. Voir cette réponse pour une liste complète.

Codes de sortie utilisés par Spark

Dans les sources Spark j'ai trouvé les codes de sortie suivants. Leurs descriptions sont tirées des déclarations de journal et des commentaires dans le code et de ma compréhension du code où le statut de sortie est apparu.

Pilote CLI Spark SQL dans Hive Thrift Server

  • 3: si une exception UnsupportedEncodingException s'est produite lors de la configuration des flux stdout et stderr.

Étincelle/fil

  • 10: si une exception non interceptée s'est produite
  • 11: si plus de spark.yarn.scheduler.reporterThread.maxFailures Échecs d'exécuteur se sont produits
  • 12: si le thread reporter a échoué avec une exception
  • 13: si le programme s'est terminé avant que l'utilisateur n'initialise le contexte spark ou si le spark ne s'est pas initialisé avant un timeout.
  • 14: Ceci est déclaré comme EXIT_SECURITY Mais jamais utilisé
  • 15: si une classe d'utilisateurs a levé une exception
  • 16: si le hook d'arrêt appelé avant le statut final a été signalé. Un commentaire dans le code source explique le comportement attendu des applications utilisateur:

    L'état par défaut de ApplicationMaster échoue s'il est appelé par un arrêt du hook. Ce comportement est différent de la version 1.x. Si l'application utilisateur est fermée à l'avance en appelant System.exit(N), marquez ici cette application comme ayant échoué avec EXIT_EARLY. Pour un bon arrêt, l'utilisateur ne doit pas appeler System.exit(0) pour terminer l'application.

Exécuteurs

  • 50: Le gestionnaire d'exceptions non capturé par défaut a été atteint
  • 51: Le gestionnaire d'exceptions non capturé par défaut a été appelé et une exception s'est produite lors de la journalisation de l'exception
  • 52: Le gestionnaire d'exceptions non intercepté par défaut a été atteint et l'exception non interceptée était une OutOfMemoryError
  • 53: DiskStore n'a pas réussi à créer un répertoire temporaire local après plusieurs tentatives (mauvais spark.local.dir?)
  • 54: ExternalBlockStore n'a pas pu s'initialiser après plusieurs tentatives
  • 55: ExternalBlockStore n'a pas réussi à créer un répertoire temporaire local après plusieurs tentatives
  • 56: L'exécuteur n'est pas en mesure d'envoyer des pulsations au pilote plus de "spark.executor.heartbeat.maxFailures" fois.

  • 101: Renvoyé par spark-submit si la classe principale enfant n'a pas été trouvée. En mode client (option de ligne de commande --deploy-mode client), La classe principale enfant est la classe d'application soumise par l'utilisateur (--class CLASS). En mode cluster (--deploy-mode cluster), La classe principale enfant est la classe de soumission/client spécifique au gestionnaire de cluster.

Codes de sortie supérieurs à 128

Ces codes de sortie résultent très probablement d'un arrêt de programme déclenché par un signal Unix. Le nombre de signaux peut être calculé en soustrayant 128 du code de sortie. Ceci est expliqué plus en détail dans ce article de blog (qui était à l'origine lié dans cette question ). Il y a aussi un bon réponse expliquant les codes de sortie générés par la JVM . Spark fonctionne avec cette hypothèse comme expliqué dans un commentaire dans ExecutorExitCodes.scala

Autres codes de sortie

Mis à part les codes de sortie répertoriés ci-dessus, il existe un certain nombre d'appels System.exit() dans les sources Spark définissant 1 ou -1 comme code de sortie. Pour autant que je sache que -1 semble à utiliser pour indiquer des paramètres de ligne de commande manquants ou incorrects tandis que 1 indique toutes les autres erreurs.

Signaux

Les signaux sont une sorte d'événements qui permettent d'envoyer des messages système à un processus. Ces messages sont utilisés pour demander à un processus de recharger sa configuration (SIGHUP) ou de se terminer (SIGKILL), par exemple. Une liste des signaux standard peut être trouvée dans la page de manuel signal (7) dans la section Signaux Standard.

Comme expliqué par Rick Moritz dans les commentaires ci-dessous (merci!), Les sources de signaux les plus probables dans une configuration Spark sont

  • le gestionnaire de ressources de cluster lorsque la taille du conteneur a dépassé, le travail terminé, une réduction dynamique a été effectuée ou un travail a été abandonné par l'utilisateur
  • le système d'exploitation : dans le cadre d'un système contrôlé arrêté ou si une limite de ressources a été atteinte (mémoire insuffisante, dépassement du quota, aucun espace disponible disque, etc.)
  • un utilisateur local qui a tué un travail

J'espère que cela rend un peu plus clair la signification de ces messages par spark.

47
Christoph Böhme