Fwd: Re: [CRIU] Signalling processes before CRIU/after unCRIU

[Andrew Vagin]

On Wed, Oct 10, 2012 at 09:27:50PM +0400, Andrew Vagin wrote:
> On Wed, Oct 10, 2012 at 06:26:59PM +0400, Alex/AT wrote:
> > > When we dump a container should we make sure systemd knows how to talk
> > > to the rest of the zoo? This sounds ... strange.
> > Yep. And determination of "parent" may be non-trivial too. It is probably
> > best to be left to the user to signal the "parent" process.
> > 
> > When we suspend a large tree from the parent, all the child processes
> > should got signalled before suspending, and be waited for each one to
> > respond (or not respond). Each one may be execution-halted after getting
> > response, and then all the non-responding processes in the tree should be
> > execution-halted at once.
> > 
> > > Frankly, I don't want to re-invent TCP for such a simple case.
> > It's not even needed. You were thinking about library mechanism, and that
> > is the best way in terms of predictability.
> 
> It's needed, because it's an easiest way to spread this functionality.
> 
> Nobody wants to link an additional library, because it is unreliably
> and insecure. In particular if there is not used a standard mechanism
> (like dbus).
> 
> I think we should look at dbus documentation. If we find nothing, we
> can ask an advice in a dbus maillist. And if all attempts are failed,
> we can start to create own mechanism.

Ok, I made a first step. An application can register an object and
then CRIU can list objects by a predefined path.

I attached two files:
test_app.py [OBJ_NAME] - emulate an application, which registers one
object com.criu.OBJ_NAME. It can be executed several times with
different names.

criu-emu.py - emulate crtools. It enumerates all objects com.criu.* and
executes a method prep() for each of them.

"""
The method's definition may require certain information to be passed
with the request as arguments (input parameters). For every request, a
reply message carries the result back to the requester, along with
either result data (output parameters) or, if the action could not be
performed, exception information. Exceptions will contain at least an
exception name and an error message.
"""

>From all of this, I can say, that dbus can do all thing, which we need.

http://www.freedesktop.org/wiki/IntroductionToDBus