[CRIU] PID mismatch problem

[Federico Reghenzani]

Ok, I'm trying to restore in a new namespace (I would prefer this solution
to start the orted directly in a dedicated namespace), but I can't do it
with C API. From command line via ssh:

ssh root at 10.10.1.2 unshare -p --fork criu restore -D /tmp/ckpt_B2BLJ

it works (even if it provides some error messages), but using orted-restore
in C API:

    unshare(CLONE_NEWPID);
    if (pid != 0) {
         ...
    }
    // getpid == 1 now
    dir = ...
    criu_init_opts();
    criu_set_images_dir_fd(dir);
    criu_set_log_file("criu_restore.log");
    criu_set_log_level(4);
    int status = criu_restore_child();
//or int status = criu_restore();

I obtain:

    Error (image.c:405): Can't open dir /proc/1/fd/11: No such device or
address
    Error (cr-service.c:254): Can't open images directory: No such device
or address

I've never used unshare, so I probably missed something ;-)

----

P.S. the tty problem happens only when I open an ssh session and then
execute the command (sshd: root at pts/0), no problem if I call criu restore
directly from ssh command (sshd: root at notty).

Cheers,
Federico
__
Federico Reghenzani
M.Eng. Student @ Politecnico di Milano
Computer Science and Engineering



2015-12-22 9:48 GMT+01:00 Cyrill Gorcunov <gorcunov at gmail.com>:

> On Tue, Dec 22, 2015 at 09:16:54AM +0100, Federico Reghenzani wrote:
> ...
> >
> >      Btw, maybe you would be able to start restore under the strace?
> >      Something
> >      like "strace -f -o /log.txt -s 512 criu restore ..." and show us the
> >      /log.txt?
> >      If run under criu service, then the service itself might be started
> with
> >      strace if i'm not missing something obvious.
> >
> >    Attached!
>
> Frederico, you're running restore on the live systems without use any of
> namespaces, for sure without them there is no reliable way to guarantee
> the PIDs match on restore. Have you been considering running your
> application
> in own at lest PID namespace? (take a look on unshare(1) manual). Just
> found that Pavel already mentioned this concern in email earlier.
>
>         Cyrill
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151222/7b5a1777/attachment-0001.html>