【发布时间】：2013-04-16 21:42:47
【问题描述】：
可以使用进程的核心转储来实现检查点/重启吗？核心文件包含进程的完整内存转储，因此理论上应该可以 将进程恢复到转储核心时的相同状态。
【问题讨论】：
-
其实我是在请求一个特定的进程。由于文件描述符表是由内核维护的，因此不位于进程的地址空间中，恢复文件描述符可能会很麻烦。跨度>
标签： linux coredump checkpoint
【发布时间】：2013-04-16 21:42:47
【问题描述】：
是的，这是可能的。 GNU Emacs 这样做是为了优化它的启动时间。它加载一堆 Lisp 文件以生成图像，然后转储一个可以重新启动的核心。
几年前，我为 GNU Make 3.80 创建了一个补丁来做同样的事情（使用从 GNU Emacs 借来的代码）。
有了这个补丁，你在 make 中有一个新选项：make --dump。该实用程序现在读取您的Makefile，然后不执行规则，而是生成一个核心转储，可以重新启动该核心转储以进行实际构建（评估已解析的规则树）。
这是一个节省，因为项目太大了，在源代码树中加载所有的 make 规则需要 30 秒！通过这种优化，增量构建几乎可以立即启动，而不会造成半分钟的启动损失。
这不需要内核支持。需要了解核心文件的结构。
除了这种方法，多年前还有一个针对 Linux 的进程检查点项目（想知道发生了什么）。
【讨论】：
-
您能否通过代码链接和更多参考资料来丰富您的答案？
-
我可以，但这需要一些工作。
make补丁从未向公众发布，因此我必须挖掘一些离线的存档磁盘才能找到它。 GNU emacs 核心转储代码很容易在 C 源代码的小核心中找到。 -
Emacs 的
unexec不是转储 core 文件，而是实现一些持久性堆机制，这并不完全一样。原始海报可以使用一些检查点库，如ftg.lbl.gov/projects/CheckpointRestart 另见en.wikipedia.org/wiki/Checkpointing
正如我所评论的，您可以查找 application checkpoint 并使用一些库，例如 Berkley Lab Checkpoint & Restart。但是，这些库并不完全使用core(5) 转储文件，并且对于检查点程序可以做什么以及检查点映像中的持久性有几个限制和约定。 （打开的文件描述符和网络套接字通常不能持久化）。
一些 Unix（可能还有一些修补过的 Linux 内核）在内核本身中具有有限的检查点设施（在 1980 年代，Cray Unix 有一些）。
【讨论】：
不，如果没有内核的特殊支持，这通常是不可能的。内核维护了很多每个进程的状态，例如文件描述符表、IPC 对象等。
如果您愿意做出许多简化假设，例如没有打开的文件、没有打开的套接字、没有活动的 IPC 对象、没有共享内存区域等等，那么理论上会是可能，但在实践中我不相信即使有这些让步，Linux 也是可能的。
【讨论】：
-
所有信息都在 DDR 上，为什么无法将机器恢复到崩溃前的确切状态？
-
@0x90: 不可能检查点整个状态，因为套接字、IPC 等...不仅取决于检查点进程，还取决于外部因素（其他进程、远程 TCP 连接等） ...)
Debian 有许多你可能想看看的软件包：
- blcr-util - 检查点和重启 Linux 进程的用户空间工具
这与 BLCR (Berkeley Lab Checkpoint/Restart) 有关，请参阅https://upc-bugs.lbl.gov/blcr/doc/html/FAQ.html#whatisblcr
-
criu - 用户空间中的检查点和恢复https://criu.org/Main_Page
2.1 docker - 最新版本支持检查点，见https://criu.org/Docker
2.1。 containerd - 控制 runC 的守护进程
这包含一个有趣的检查点设施。
另请参阅支持实时迁移的 openvz： https://openvz.org/Checkpointing_and_live_migration
【讨论】：
-
news.ycombinator.com/item?id=12180914 看到这篇文章有很多讨论。