退出代码和退出状态是否意味着什么火花？

Question

在纱线上运行火花时,我一直看到退出代码和退出状态:

以下是一些:

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

我从来没有发现任何这些消息是有用的......有没有机会解释这些消息究竟出了什么问题？我搜索了高低不一的表格来解释错误,但没有.

我能够从上面解释的唯一一个是退出代码52,但那是因为我在这里查看了源代码.这是说这是一个OOM.

我是否应该停止尝试解释其余的退出代码并退出状态？或者我错过了一些明显的方式,这些数字实际意味着什么？

即使有人能告诉我之间的差异exit code,exit status以及SIGNAL这将是有益的.但我现在只是随机猜测,而且我周围的其他所有人都使用了火花.

最后,为什么一些退出代码小于零以及如何解释这些？

例如 Exit status: -100. Diagnostics: Container released on a *lost* node

Answer 1

退出代码和状态以及信号都不是特定于Spark的,但是部分过程在类Unix系统上工作.

退出状态和退出代码

退出状态和退出代码是同一事物的不同名称.退出状态是0到255之间的数字,表示终止后的进程的结果.退出状态0通常表示成功.其他代码的含义取决于程序,应在程序文档中描述.但是,有一些既定的标准代码.请参阅此答案以获取完整列表.

在Spark源代码中,我找到了以下退出代码.它们的描述来自代码中的日志语句和注释,以及我对退出状态出现的代码的理解.

10:如果发生了未捕获的异常
11:如果spark.yarn.scheduler.reporterThread.maxFailures发生超过遗嘱执行人的失败
12:如果记者线程因异常而失败
13:如果程序在用户初始化spark上下文之前终止,或者如果spark函数在超时之前没有初始化.
14:这被声明为EXIT_SECURITY但从未使用过
15:如果用户类引发了异常
16:如果报告了在最终状态之前调用的关闭钩子.源代码中的注释解释了用户应用程序的预期行为:

ApplicationMaster如果由关闭挂钩调用,则默认状态为失败.与1.x版本相比,此行为有所不同.如果通过调用提前退出用户应用程序System.exit(N),则此处将此应用程序标记为失败EXIT_EARLY.为了获得良好的关闭,用户不应该调用 System.exit(0)终止应用程序.

50:已达到默认的未捕获异常处理程序
51:调用默认的未捕获异常处理程序,并在记录异常时遇到异常
52:已达到默认的未捕获异常处理程序,未捕获的异常是OutOfMemoryError
53: DiskStore经过多次尝试后无法创建本地临时目录(错误的spark.local.dir？)
54:多次尝试后,ExternalBlockStore无法初始化
55:多次尝试后,ExternalBlockStore无法创建本地临时目录
56:执行者无法向"驱动程序"发送心跳超过"spark.executor.heartbeat.maxFailures"次.
101:如果找不到儿童主要班级,则通过spark-submit返回.在客户端模式(命令行选项--deploy-mode client)中,子主类是用户提交的应用程序类(--class CLASS).在集群模式(--deploy-mode cluster)中,子主类是特定于集群管理器的提交/客户端类.

这些退出代码很可能是由Unix信号触发的程序关闭引起的.可以通过从退出代码中减去128来计算信号编号.这个博客文章(最初在这个问题中链接)更详细地解释了这一点.解释JVM生成的退出代码也有一个很好的答案.Spark使用这个假设,如ExecutorExitCodes.scala中的注释所述

除了上面列出的退出代码外,System.exit()Spark源设置1或-1中的调用次数为退出代码.据我所知,-1似乎用于表示缺少或不正确的命令行参数,而1表示所有其他错误.

信号是一种允许将系统消息发送到进程的事件.例如,这些消息用于请求进程重新加载其配置(SIGHUP)或终止自身(SIGKILL).标准信号列表可以在标准信号部分的signal(7)手册页中找到.

正如Rick Moritz在下面的评论中所解释的那样(谢谢!),Spark设置中最可能的信号来源是

我希望通过spark可能意味着这些消息更加清晰.