Veo códigos de salida y la de salida de los estados de todo el tiempo cuando se ejecuta chispa en el hilo:

Aquí están algunos:

  • 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...

Nunca he encontrado a alguno de estos mensajes como útil….¿Hay alguna posibilidad de interpretar lo que realmente va mal con estos? He buscado de alta y baja para una tabla que explica los errores, pero nada.

El ÚNICO que soy capaz de descifrar a partir de los de arriba es el código de salida 52, pero eso es porque he mirado el código fuente aquí. Es decir que es un OOM.

Debo dejar de tratar de interpretar el resto de estos códigos de salida y la de salida de los estados? O me estoy perdiendo algo de manera obvia que estos números significan algo?

Incluso si alguien podría decirme la diferencia entre exit code, exit status, y SIGNAL que sería útil. Pero yo soy sólo al azar acertar ahora, y parece que todos los demás que me rodean y que utiliza chispa es, demasiado.

Y, finalmente, ¿por qué son algunos de los códigos de salida menor que cero, y cómo interpretar los?

E. g. Exit status: -100. Diagnostics: Container released on a *lost* node

InformationsquelleAutor Sother | 2017-08-01

1 Comentario

  1. 43

    Ni códigos de salida y de estado ni señales de Chispa específico, sino en parte de la manera en que los procesos de trabajo en los sistemas tipo Unix.

    Estado de salida y el código de salida

    Estado de salida y códigos de salida son diferentes nombres para la misma cosa. Un estado de salida es un número entre 0 y 255 que indica el resultado de un proceso después de que termina. Estado de salida 0 por lo general indica éxito. El significado de los otros códigos es un programa dependiente y debe ser descrito en la documentación del programa. Hay algunos establecido códigos estándar, sin embargo. Ver esta respuesta para una lista completa.

    Códigos de salida utilizado por Chispa

    En el Chispa fuentes encontré el siguiente
    códigos de salida. Sus descripciones son tomadas de registro de declaraciones y comentarios en el código y de mi comprensión del código, donde el estado de salida apareció.

    Chispa SQL CLI Conductor de la Colmena de Ahorro Servidor

    • 3: si un UnsupportedEncodingException se produjo cuando la configuración de stdout y stderr arroyos.

    Chispa/Hilados

    • 10: si una excepción no capturada se produjo
    • 11: si más de spark.yarn.scheduler.reporterThread.maxFailures ejecutor ocurrieron
    • 12: si el periodista hilo de error con una excepción
    • 13: si el programa termina antes de que el usuario ha inicializado la chispa contexto o si la chispa contexto no inicializar antes de un tiempo de espera.
    • 14: Este es declarado como EXIT_SECURITY pero nunca
    • 15: si un usuario de la clase lanzó una excepción
    • 16: si el cierre de gancho llamado antes de final de estado fue reportado. Un comentario en el código fuente, explica el comportamiento esperado de las aplicaciones de usuario:

      El estado predeterminado de ApplicationMaster es un error si es invocada por apagar gancho.
      Este comportamiento es diferente en comparación a 1.x versión.
      Si el usuario de la aplicación se sale antes de tiempo llamando System.exit(N), aquí marca
      esta aplicación falló con EXIT_EARLY. Para un buen cierre, el usuario no debería llamar
      System.exit(0) para terminar la aplicación.

    Ejecutores

    • 50: El valor predeterminado excepción no capturada fue alcanzado
    • 51: El valor predeterminado excepción no capturada fue llamado y una excepción se encontró al registro de la excepción
    • 52: El valor predeterminado excepción no capturada fue alcanzado, y la excepción no capturada fue un OutOfMemoryError
    • 53: DiskStore no se pudo crear el directorio temporal local después de muchos intentos (mala chispa.local.dir?)
    • 54: ExternalBlockStore no se pudo inicializar después de muchos intentos
    • 55: ExternalBlockStore no se pudo crear un directorio temporal local después de muchos intentos
    • 56: Albacea no puede enviar los latidos del corazón para el controlador más de «chispa.ejecutor.el latido del corazón.maxFailures» veces.

    • 101: Devuelto por chispa-presentar si el niño de la clase principal no se encontró. En el modo cliente (opción de línea de comandos --deploy-mode client) el niño de la clase principal es que el usuario envió clase de aplicación (--class CLASS). En el modo de clúster (--deploy-mode cluster) el niño de la clase principal es el administrador de clúster específico de presentación/de la clase cliente.

    Códigos de salida de más de 128

    Estos códigos de salida más probable es que el resultado de un programa de cierre provocado por
    un Unix de la señal. El número de señal puede ser calculado restando a 128 del código de salida. Esto se explica en más detalle en esta blog (que originalmente fue vinculado en esta pregunta). También hay una buena respuesta explicando JVM-genera códigos de salida. Chispa funciona con este supuesto, como se explica en un comentario en ExecutorExitCodes.scala

    Otros códigos de salida

    Aparte de la salida de los códigos mencionados anteriormente hay una serie de System.exit() llamadas en la Chispa de fuentes de ajuste 1 o -1 como código de salida. Tan lejos como puedo decirle a un -1 parece ser utilizado para indicar que falta o incorrecta de parámetros de línea de comandos, mientras que 1 indica que todos los demás errores.

    Señales

    Señales son un tipo de eventos que permiten enviar mensajes de sistema a un proceso. Estos mensajes se utilizan para pedir un proceso para volver a cargar su configuración (SIGHUP) o a rescindir el mismo (SIGKILL), por ejemplo. Una lista de las señales estándar se puede encontrar en la la señal(7) el hombre de la página en la sección las Señales Estándar.

    Según explicó Rick Moritz abajo en los comentarios (¡gracias!), las fuentes más probables de las señales en una Chispa de instalación son

    • la de recursos de clúster manager cuando el tamaño del recipiente superado, el trabajo terminado, el dinamismo de la escala-hacia abajo, o un trabajo que fue abortado por el usuario
    • la sistema operativo: como parte de un sistema de control para apagar o si algunos de límite de recursos fue de golpe (fuera de la memoria, sobre la cuota de disco duro, no queda espacio en el disco, etc.)
    • un de usuario local que mató a un trabajo

    Espero que esto hace que sea un poco más claro lo que estos mensajes por chispa podría significar.

    • Creo que la pregunta fue el objetivo de la chispa de específicas razones/causas de lo que en realidad provoca la señal. También, desde el código Java o JVM en sí es la generación de los códigos de salida, creo que puede ser más específico que el estándar de los códigos.
    • Muchas gracias por su aportación. Voy a tratar de ampliar mi respuesta y añadir algunos detalles más en el real de la salida de los códigos utilizados por la JVM y la Chispa en el día de hoy.
    • He añadido una sección sobre la salida de los códigos utilizados por Chispa. Como no los he usado Chispa de mí, en la nomenclatura de los componentes puede no ser correcta. Todavía creo que la lista es bastante útil.
    • sí, es cierto que estoy más interesado en la chispa razones específicas/códigos. Pero esto todavía es útil.
    • Estoy teniendo problemas para ver que código de salida correspondería a algo similar a tener demasiados o demasiado pocos particiones. Me estoy perdiendo lo que me dicen que es un problema de particionamiento? O es la partición de un síntoma y no una enfermedad?
    • Tan lejos como puedo saber el número de particiones es sobre todo un factor de optimización. Si es demasiado pequeño paralelismo no es explotado en su totalidad. Si es demasiado grande la sobrecarga de la comunicación se pone en alto. Sin embargo, la Javadoc en el Particionador de clase sugiere que OOMs son un indicador de mal particionado. Estás viendo cualquier otra códigos de salida de los mencionados anteriormente?
    • Muy bien hecho. Creo que un punto extra a añadir sería la fuente de las señales: Suele ser el recurso de clúster manager (tamaño del envase superado, trabajo terminado, la dinámica de la escala-hacia abajo, trabajo abortado por el usuario), el sistema operativo (sistema de control de apagado, fuera de la memoria, sobre la cuota de disco duro, no queda espacio en el disco, etc.), o un usuario local (matar). No debe haber otras entidades de envío de señales para encender la Chispa de los procesos.
    • Eso es muy bueno, además de verdad. Me incorporé en la respuesta. Espero que esto y la forma en la que se le atribuyen está bien para usted.
    • bien. Soy yo el único que wees Exit code 143 con más frecuencia que cualquier otro código de salida?
    • de todos modos felicidades impresionante respuesta
    • ¿Te importaría elaborar un poco sobre exit code 15? cuando usted dice «código de usuario» supongo que te refieres a como una costumbre UDF o algo? En cuyo caso, ¿por qué SIGTERM 15 por lo general significa una OOM y no necesariamente una costumbre UDF?
    • Además, la diferencia entre 1) de la clase principal de la puesta en marcha de medio ambiente y 2) el usuario principal de la clase. ¿Cuál es la diferencia entre ellas?
    • sí, las buenas ideas – cuidado para añadir una respuesta ? 🙂
    • También, supongo SIGKILL y SIGTERM son la misma cosa?
    • No exactamente: SIGTERM pide un proceso a favor de terminar el mismo. Un proceso puede ignorar esta petición. SIGKILL en la otra simplemente se mata a un proceso sin preguntar el proceso.
    • Lo que yo veo. Me he dado cuenta de que YY/mm/dd HH:MM:ss INFO yarn.ApplicationMaster: Registered signal handlers for [TERM, HUP, INT] se muestra en mi hilo de los registros con frecuencia y me pregunto ¿que tiene que ver con él.
    • Estos mensajes de registro sólo decir que el ApplicationMaster quiere recibir las señales SIGTERM, SIGHUP y SIGINT para que pueda reaccionar a ellos. Chispa parece a instalar un manejador de señal para estas tres señales que simplemente registra una «SEÑAL RECIBIDA mensaje».
    • Gran. Yo también estoy curioso lo que significa que cuando el estado de salida es menor que 0? He editado esta en mi pregunta. gracias.
    • He encontrado este post porque tengo exactamente el mismo Exit status: -100...*lost* node como el OP. Esta es una gran respuesta, pero no veo ninguna mención de que. Cualquier idea acerca de estos negativo códigos de salida (aparte de la -1 lo que indica un CLI error)? Gracias!
    • Es de todos modos hay que volver una costumbre código de retorno de la chispa de trabajo. Hemos escrito una validación del trabajo en la chispa y queremos pasar un par de códigos de retorno que indica el tipo de error de validación, el shell script que invoca la chispa a presentar. Estamos utilizando el Sistema.salida(1001) para devolver el código de salida

Dejar respuesta

Please enter your comment!
Please enter your name here