[Lxc-users] Running DMTCP inside a LXC container

[Alexandre Gravier]

Hello,

I'm trying to use DMTCP to save my user sessions on an online service
that offers LXC virtual machines. The service shutdowns the container
after 15 minutes of inactivity on my side, and I would like to be able
to save my tmux session and all related processes to disk before that
happens.

So, I've compiled DMTCP 2.0, and 40 out of 45 tests pass*. I figured
that I may try to do something simple first, so I launch the
coordinator in a terminal, and `bin/dmtcp_launch cat` in another. The
coordinator notes that "NOTE at dmtcp_coordinator.cpp:1039 in
onConnect; REASON='worker connected'". It all seems fine, and the
clients list contains my cat.

The problem comes when I actually make a checkpoint using 'c' in the
coordinator. The coordinator goes through what seems to be a
reasonable list of stages, from "starting checkpoint, suspending all
nodes" to "restarting all nodes", but in the terminal where the
dmtcp-monitored "cat" is running, there is an avalanche of errors that
all look like:

[11795] mtcp_writeckpt.c:718 write_ckpt_to_file:
  ERROR: error statting
/var/lib/lxc/vm-524f2a6f88716f1d3800785a/overlay/home/agravier/dmtcp-2.0/plugin/ipc/libdmtcp_ipc.so
: No such file or directory
[11795] mtcp_writeckpt.c:718 write_ckpt_to_file:
  ERROR: error statting
/var/lib/lxc/rootfs/lib/x86_64-linux-gnu/ld-2.17.so : No such file or
directory

And there are dozens of those.

Visibly, mtcp is looking for files using their absolute path *outside*
of the LXC container, which, of course, does not correspond to their
paths inside of it.

I would like to understand how LXC chroots in a way that still allows
MTCP to get hold of the original filepaths. Why does MTCP get confused
when other applications don't? Or rather, why it doesn't get confused
by LXC :) ?

Is there is anything that I might do about all that?

Thanks and regards,
Alexandre


* Failing tests: shared-memory (rstr), pty2, bash (rstr), script, screen.