6

我在 EC2 现货实例上运行一些应用程序。此类实例可能会在没有通知的情况下被 Amazon 杀死。

在关闭过程中，进程按某种顺序被杀死。我们有监控/恢复程序，它们的行为应该根据服务器是关闭还是进程刚刚崩溃而有所不同。（特别是如果服务器实际上正在关闭，我们不想做任何事情）

如何在恢复过程中（如果它仍然存在）检测到进程因关闭而被杀死？

（更多系统细节：我在不修改外部状态的沙箱中运行未知/不受信任/等代码。通常如果沙箱代码崩溃，这是不受信任代码的作者的错，我们不会重新运行它。但如果沙盒代码由于VM关闭或失败而终止，我们需要在另一个实例上重新运行它。我现在遇到的问题是用户的代码首先被终止，所以监控程序错误地认为崩溃是用户错误.)

4

4 回答 4

5

代理人

在产生沙箱子进程的每台机器上运行一个代理。代理运行您的“防崩溃”代码，沙盒代码运行可能崩溃的用户代码。

负责启动具有新沙箱进程的新机器的监控系统检查哪些进程已被杀死（代理和沙箱进程或仅沙箱子进程）。

它通过向代理查询其子进程的 TCP 连接 (RMI/RPC/HTTP) 来实现这一点。如果代理响应 - 机器仍在运行，并且可以询问其子沙箱进程。如果代理没有响应 - 机器被怀疑被终止。

代理（变体）

该代理还负责在同一 VM 上重新启动子沙箱进程，以防它崩溃。

查询服务

使用查找服务（例如 Zoo Keeper）来跟踪哪些进程发送了心跳保持活动。如果代理还活着，那么机器仍在运行，如果代理不活跃，那么它就没有运行。

ec2 接口

轮询 EC2 API 以确定机器是处于运行状态还是终止状态。

于 2012-06-02T07:42:23.453 回答
2

您的恢复过程如何进行？

如果您正在使用waitpid监视进程，当它退出时，您可以确定：

  • 是否正常退出，如果退出，进程返回什么状态，或者
  • 它是否因信号而退出，以及该信号是什么。

根据进程的关闭方式，我希望看到它正常退出或通过SIGTERMor退出SIGKILL。SIGILL, SIGABRT, SIGFPE, SIGBUS, SIGSEGV, 和SIGSYS表示因编程错误而崩溃。

于 2012-05-31T00:30:43.660 回答
1

这听起来像是一个非常脆弱的计划。不要试图检测系统的状态：让你的应用程序写出一个有效性令牌（并同步相关文件！）以某种方式遵循应用程序的“干净”关闭/暂停/停止并使用它。

于 2012-05-21T23:25:18.230 回答
0

我假设当实例关闭时，您的监控进程会收到一个 SIGTERM 信号。

那么是否有可能做类似的事情 - 如果受监控的进程已经退出 && 在接下来的 5 秒内没有收到 SIGTERM 信号 - 假设进程崩溃了。如果收到 SIGTERM，只需退出信号处理程序。

于 2012-06-05T16:48:19.330 回答