jpetazzo/critmux

Docker + CRIU + tmux = magic!

Freeze. Thaw. Repeat.

This is a tech demo of CRIU and Docker integration, featuring tmux.

See it live in this ASCII video demo!

1. docker run -t -i --privileged --name critmux jpetazzo/critmux
2. Do stuff in tmux. Don't know what to do? Just type a few characters.
3. From another terminal, docker stop critmux. Container stops.
4. docker start critmux ; docker attach critmux. MIND. BLOWN.

Note: docker start -a doesn't quite work.

What the?

This container starts a little wrapper, which sets up a SIGTERM signal handler. Then it checks if there is some saved state in /state:

• if there is no saved state, we assume a clean start, setup a tmux session, and attach to it;
• if there is a saved state, it is restored it (it should be a tmux daemon process), then we attach to tmux.

The signal handler just sends a detach command to tmux; and the wrapper arranges for the state to be saved when tmux is detached. In other words, when detaching from tmux, or when sending SIGTERM, or when doing docker stop on the container, we end up saving its state.

Requirements

You need a fairly recent kernel. Debian's 3.14 works; some people reported that 3.13 didn't.

AUFS won't work.

critmux's Issues

Can't dump tmux process

I followed your instruction and when I stopped the container, it fails to dump the tmux process with the following error.

Error (kerndat.c:44): Can't stat self map_files: No such file or directory
Error (cr-dump.c:1863): Dumping FAILED.
Traceback (most recent call last):
  File "/usr/local/sbin/wrapper", line 28, in <module>
    system("criu dump --tree {} --images-dir /state".format(pid))
  File "/usr/local/sbin/wrapper", line 9, in system
    return subprocess.check_call(cmd, shell=True)
  File "/usr/lib/python3.4/subprocess.py", line 557, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command 'criu dump --tree 10 --images-dir /state' returned non-zero exit status 1

Apparently, map_files are missing on this image.

root@404b50795b6c:/src# find /proc/ | grep map_file

According to http://lwn.net/Articles/574918/ it seems the kernel is built without CONFIG_CHECKPOINT_RESTORE option.

But in your demo, it was certainly working. Does this still work for you?

Thanks.