[CRIU] PID mismatch problem

[Federico Reghenzani]

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

> On Tue, Dec 22, 2015 at 11:37:55AM +0100, Federico Reghenzani wrote:
> > 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);
>         fork();
>
> After unshare you need to call a fork as far as I remember
> and continue inside child.
>
>
Yes sorry, the fork is there, it's a copy-and-paste error.


> >     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).
>
> So you borrow the 0 index for sshd itself I guess, that;s why criu
> is complaining. I think you shouldn't do that (but I'm not sure
> how internally sshd operates with pty devices)
>

Ok, anyway it's not currently a problem.

2015-12-22 11:52 GMT+01:00 Pavel Emelyanov <xemul at parallels.com>:

> On 12/22/2015 01:37 PM, Federico Reghenzani wrote:
> > 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.
>
> Well, yes, the C API is not yet up to this.
>
> You can try to call unshare() glibc function by hands before fork()-ing and
> exec()-ing criu. This would be good approximation of what my --unshare
> patchset
> does. Or pick one up and add respective calls to lib/criu.c, this
> contribution
> will be accepted with gratitude :)
>

Ok, I guess I can try to add them :)

> From command line via ssh:
> >
> > ssh root at 10.10.1.2 <mailto: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
>
> That's because you only spawned new pid namespace, but the /proc remained
> the same
> showing pids from wrong (previous) namespace. If you use -m and
> --mount-proc that
> would help.
>

Thanks I will try it in a few hours.


>
> >     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
>
> -- Pavel


Cheers,
Federico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20151222/88c457c7/attachment.html>