[CRIU] Process with TCP migrated successfully but some errors occurred

[Pavel Emelyanov]

On 07/02/2014 06:05 PM, Oscar Fernández wrote:
> Hi all and congratulations for your work,
> 
> I made a simple server-client TCP application in python (similar to "Simple TCP pair" example in the wiki).
> I'm running client and server processes in two different machines, and I'm moving the server side process to a third machine.
> 
> The steps I'm following are as follows:
> - [src] Dump the server process using NFS and --tcp-established option
> - [src] Disabling the interface used by the dumped process (ifconfig ethX down)
> - [dst] Enabling an interface with the ip used by the process (ifconfig x.x.x.x/x ethX)**
> - [dst] Restore the server process using image files in NFS and --tcp-established option
> 
> **Notice that I'm just setting the same IP addr in the destination machine (I'm not configuring the MAC addr). Please, can you explain how is it working? I mean, I thought it would fail since the iface is not identical. Is CRIU sending a flush message to remove the old MAC addr entry in the switch or something?
> 
> 
> The restoration is success and the communication with the client is immediately re-established, but
> I spotted few errors either in dump and restore log files (find both attached).
> 
> Can you explain what are and what is provoking these errors?

On dump there are two errors like

  Error (parasite-syscall.c:387): si_code=1 si_pid=2882 si_status=0

there are due to some missed stop notifications from parasite
code. They are harmless, but yes, worth being researched more
deeply and get fixed.

On restore the error is like this

(00.327540) Error (netfilter.c:69): Iptables configuration failed: No such file or directory
(00.327572)     Running iptables [iptables -t filter -D OUTPUT --protocol tcp --source 10.1.1.102 --sport 8088 --destination 10.1.1.1 --dport 38544 -j DROP]

These are worse, but don't fail the restore (probably should). They
say, that the connection wasn't locked on the destination node with
the netfilter rule.

When you use the --tcp-established option, criu on dump locks the
connection with the netfilter rule like the one in the error message
and expects this rule to be present on the destination node at the
restore time.

Thanks,
Pavel