[CRIU] Signalling processes before CRIU/after unCRIU

Pavel Emelyanov xemul at parallels.com
Wed Oct 10 09:46:12 EDT 2012


On 10/10/2012 05:37 PM, Alex/AT wrote:
> It may have some sense to plan/discuss this mechanism a bit then. I assume  
> we have two category of processes:
> 
> 1. Processes that know about CRIU
> 2. Processes that do not know about CRIU
> 
> On the first look, (1) category suspend may be processed as follows:
> 1. At the start of CRIU work, send "DO YOU KNOW ME? START SUSPEND" signal  
> to the process.
> 2. Getting "ROGER" response (a message passing or a callback mechanism  
> with sensible timeout may be implemented), we know that the process is in  
> category (1).

Consider you have not one task, but a process tree. Will you wait for a timeout
on each, or give one timeout for them all to respond?

> 3. Then we wait for "COMPLETE" callback/response for a definite time (or  
> indefinite, specified on user behalf).
> 4. If "COMPLETE" is received, process is ready, and we suspend it. After  
> unsuspension, we send "WELCOME BACK" signal to the process, and do not  
> wait for any response.
> 5. If "COMPLETE" is not received in given time, we send "SORRY, OUTTA  
> HERE" signal to the process and abort, because the process has not  
> completed housekeeping properly. It may be nice to have user "force"  
> option here to suspend such processes in default way, without waiting for  
> completion of housekeeping, if the user knows what he/she is doing.

Now the crtools are launched again in a short period of time do try dump the
task again, send the "START SUSPEND" and suddenly receive "COMPLETE" that was
sent previously, but stuck somewhere in the signaling engine. What do we do?

> If we don't get "ROGER" response on the first request, we know the process  
> is in the (2) category, and then we may suspend it as is, without any  
> further signalling
> 




More information about the CRIU mailing list