<div dir="ltr"><div><div>&#39;s&#39; means stop.<br><br></div><div>I have used this option because without it, the restart of a container from a snapshot didn&#39;t work.<br></div><div>Test:<br>lxc-checkpoint -D /tmp/dire -n worker1  (without -s option)<br></div><div>lxc-stop -n worker1 ( i have stopped the container to test if a container restarts from a snapshot if i have a local crash of the container)<br>lxc-checkpoint -r -D  /tmp/dire -n worker1<br><br>lxc-ls -f<br>^CTraceback (most recent call last):<br>  File &quot;/usr/bin/lxc-ls&quot;, line 432, in &lt;module&gt;<br>    containers = get_containers(root=True)<br>  File &quot;/usr/bin/lxc-ls&quot;, line 261, in get_containers<br>    if container.controllable:<br>KeyboardInterrupt<br><br></div><div>bloqued. <br><br></div><div>restore.log:<br><br>Warn  (cr-restore.c:1029): Set CLONE_PARENT | CLONE_NEWPID but it might cause restore problem,because not all kernels support such clone flags combinations!<br>RTNETLINK answers: File exists<br>RTNETLINK answers: File exists<br>RTNETLINK answers: File exists<br>   610: Error (files-reg.c:1097): Can&#39;t open file tmp/libnetty-transport-native-epoll4589659792274548507.so on restore: No such file or directory<br>   610: Error (files-reg.c:1040): Can&#39;t open file tmp/libnetty-transport-native-epoll4589659792274548507.so: No such file or directory<br>   610: Error (cr-restore.c:253): Can&#39;t fixup VMA&#39;s fd<br><br></div><div><br><br></div><div><br></div><br></div>Bests.<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-25 13:27 GMT+01:00 Pavel Emelyanov <span dir="ltr">&lt;<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/25/2015 03:14 PM, Thouraya TH wrote:<br>
&gt; No, i have used -s option so it is not RUNNING.<br>
<br>
</span>What does this option mean for lxc? And what if you don&#39;t use one<br>
and just lxc-checkpoint the container instead?<br>
<br>
&gt; Kind regards.<br>
&gt;<br>
&gt; 2015-06-25 12:01 GMT+01:00 Pavel Emelyanov &lt;<a href="mailto:xemul@parallels.com">xemul@parallels.com</a> &lt;mailto:<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>&gt;&gt;:<br>
<div class="HOEnZb"><div class="h5">&gt;<br>
&gt;     On 06/25/2015 01:15 PM, Thouraya TH wrote:<br>
&gt;     &gt; Hi all,<br>
&gt;     &gt;<br>
&gt;     &gt; May be, cloning containeris the source of the problem...<br>
&gt;     &gt;<br>
&gt;     &gt; /Does it happen always? What if you try to dump this container again without restart?<br>
&gt;     &gt; /<br>
&gt;     &gt; Did you mean:<br>
&gt;     &gt;<br>
&gt;     &gt; lxc-checkpoint -s -D /tmp/dire -n worker1<br>
&gt;     &gt; lxc-start -n worker1  ( i have to restart all process needed inside the container)<br>
&gt;     &gt; lxc-checkpoint -s -D /tmp/dire1 -n worker1<br>
&gt;<br>
&gt;     Yes, but without the lxc-start in between (the container remains running after<br>
&gt;     first dump, doesn&#39;t it?)<br>
&gt;<br>
&gt;<br>
<br>
</div></div></blockquote></div><br></div>