Re: A possible idea for Linux: Save running programs to disk

[Bernard Blackham <bernard@blackham.com.au>]

On Sat, Oct 01, 2005 at 01:30:22PM -0800, lokum spand wrote:
> Suppose Linux could save the total state of a program to disk, for
> instance, imagine a program like mozilla with many open windows. I give
> it a SIGNAL-SAVETODISK and the process memory image is dropped to a
> file. I can then turn off the computer and later continue using the
> program where I left it, by loading it back into memory.

www.checkpointing.org lists several solutions for this.

I'm the author of CryoPID[1] - it's a checkpointing program that
allows you to save the state of a process to a file without any
prior thought when linking or running the process. It won't handle
an entire mozilla process, but single-threaded console-based apps
are quite feasible.  Migration between machines works too - 2.6 to
2.6 works, 2.4 to 2.4 works, 2.6 to 2.4 works, and 2.4 to 2.6 mostly
works with some TLS emulation (which might be incomplete, but can
always be improved).

Open files are reopened. Opened temporary files (unlinked) could
potentially be restored by scraping the contents out of the file
while the process in question has it open.

Networking isn't too bad really so long as you keep the same IP. TCP
sockets can be handled by tcpcp[2] which is already supported by
CryoPID. UDP sockets are pretty trivial, but not yet done. For both
of these to be reliable though, there needs to be some sort of
arrangement to drop packets on these connections whilst they are
suspended and not have the kernel send an RST back. (Thinking a
daemon that drives some iptables).

Unix sockets are indeed trickier. Mostly this is for X applications,
and for this I'm actually looking towards toolkit-based solutions as
apps can't be expected to deal with things like colour depth changes
and so on.  Gtk+ can already migrate applications between displays,
with the only issue being that not all the resources tied to the
original X server are freed, so you can't lose it. This is scheduled
to be fixed for Gtk+ 2.10 though, so I'm holding out hope for this.

Multithreading or even multiple processes will be a fun one though.
Ditto for shared memory and other IPC stuff.  Determined that it's
possible, just not sure how yet. :)

As for portability, it was written for x86 and has been ported to
AMD64, and I'm also in the middle of porting it to sparc. (ppc and
alpha planned too).

Yes, it has to do some pretty vile things to avoid modifying the
kernel or userspace programs, but it's quite suitable for doing
things like backing up your irssi sessions hourly, saving
computational jobs across a reboot or moving them to another
machine, or showing off features of an application.

Bernard.

[1] http://cryopid.berlios.de/
[2] http://tcpcp.sf.net/