[CRIU] [RFC] run each test case also in --check-only mode

Pavel Emelyanov xemul at virtuozzo.com
Mon Mar 20 05:22:27 PDT 2017


On 03/20/2017 02:39 PM, Adrian Reber wrote:
> The following patch tries to add the --check-only option to each test case.
> 
> For each test case now the following step are run:
> 
>  * dump in --check-only mode
>  * real dump
>  * restore in --check-only mode
>  * real restore
> 
> For most test cases this works successfully. Unfortunately not for network
> test cases. There are multiple problems:
> 
> ./zdtm.py run -f h -t zdtm/static/socket-tcp --check-only
> 
> === Run 1/1 ================ zdtm/static/socket-tcp
> 
> ======================= Run zdtm/static/socket-tcp in h ========================
> Start test
> ./socket-tcp --pidfile=socket-tcp.pid --outfile=socket-tcp.out
> Run criu dump in check-only mode
> Only checking if requested operation will succeed
> Run criu dump
> Run criu restore in check-only mode
> Only checking if requested operation will succeed
> Checking mode enabled
> Run criu restore
> =[log]=> dump/zdtm/static/socket-tcp/31/1/restore.log
> ------------------------ grep Error ------------------------
> (00.008036) Error (criu/util.c:707): exited, status=1
> (00.008050) Error (criu/netfilter.c:91): Iptables configuration failed
> (00.009993) Error (criu/util.c:707): exited, status=1
> (00.010007) Error (criu/netfilter.c:91): Iptables configuration failed
> ------------------------ ERROR OVER ------------------------
> Send the 15 signal to  31
> Wait for zdtm/static/socket-tcp(31) to die for 0.100000
> ############### Test zdtm/static/socket-tcp FAIL at result check ###############
> Test output: ================================
> 11:30:41.072:    31: ERR: socket-tcp.c:190: can't write (errno = 104 (Connection reset by peer))
> 
>  <<< ================================
> ##################################### FAIL #####################################
> 
> The first problem is that the network unlocking fails for the real restore.
> The '--check-only' restore already unlocked the network. Which is wrong, but
> I am not sure what the right solution is. Should I just ignore network
> unlocking in check-only mode?

I would say yes. Since you haven't done real dump, there's no why you'd
expect the network to be locked.

> The second problem seems to be that when CRIU restores the process in
> real restore mode the sockets cannot be restored again and I am not sure
> why.

Would you show the restore.log file for this case?

> So I am asking for some help how to correctly handle the network in
> --check-only mode:
>  * What should be done with the unlocking? Just skip it? Can it be simulated?
>  * What should be done with the sockets? How much can be simulated during
>    socket restore? Should it just be skipped completely?
> 
> 		Adrian
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
> .
> 



More information about the CRIU mailing list