[CRIU] failure dumping nginx in docker container

Ross Boucher rboucher at gmail.com
Tue Jun 30 15:39:28 PDT 2015


Just following up from our irc conversation, here's the daemon strace from
the docker run -d nginx:

https://gist.github.com/boucher/07af3dd6faa480323698


On Tue, Jun 30, 2015 at 11:12 AM, Ross Boucher <rboucher at gmail.com> wrote:

> Attached the failure log. It's quite short, though. I don't think I've
> changed anything else, but if this makes no sense then I can try rebuilding
> everything to ensure I've got the right setup.
>
> https://gist.github.com/boucher/74805891264e042881aa
>
> On Tue, Jun 30, 2015 at 8:29 AM, Andrew Vagin <avagin at odin.com> wrote:
>
>> Hi Boucher,
>>
>> Could you try out the attached patch?
>>
>> On Tue, Jun 30, 2015 at 05:00:36PM +0300, Andrew Vagin wrote:
>> > On Wed, Jun 24, 2015 at 12:34:51PM -0700, Ross Boucher wrote:
>> > > Here's the output same procedure without the restore-sibling option:
>> > >
>> https://gist.githubusercontent.com/boucher/b18593b9da2782d17e95/raw/strace.txt
>> > >
>> > > It's rather long. I'm not really sure how to read the strace output.
>> >
>> > Thank you.
>> >
>> > 16272 write(1023, "(00.139818)      1: \t\tCreate transport fd
>> /crtools-fd-1-5\n", 58) = 58
>> > 16272 socket(PF_LOCAL, SOCK_DGRAM, 0)   = 0
>> > 16272 bind(0, {sa_family=AF_LOCAL, sun_path=@"/crtools-fd-1-5"}, 18) = 0
>> > 16272 fcntl(5, F_GETFD)                 = -1 EBADF (Bad file descriptor)
>> > 16272 dup2(0, 5)                        = 5
>> >
>> > 16272 write(1023, "(00.142054)      1: Found id pipe:[122747] (fd 8) in
>> inherit fd list\n", 69) = 69
>> > 16272 dup(8)                            = 9
>> > 16272 write(1023, "(00.142074)      1: File pipe:[122747] will be
>> restored from fd 9 duped from inherit fd 8\n", 90) = 90
>> > 16272 fcntl(5, F_GETFD)                 = 0
>> > 16272 write(1023, "(00.142095)      1: Error (util.c:131): fd 5 already
>> in use (called at files.c:872)\n", 84) = 84
>> >
>> > Looks like we meet both ends of an inhereted pipe.
>> >
>> > The same problem can be reproduced by the pipes test with the following
>> > path:
>> >
>> > diff --git a/test/pipes/pipe.c b/test/pipes/pipe.c
>> > index cb34703..03efccc 100644
>> > --- a/test/pipes/pipe.c
>> > +++ b/test/pipes/pipe.c
>> > @@ -232,7 +232,7 @@ int main(int argc, char *argv[])
>> >
>> >                 child_pid = getpid();
>> >
>> > -               close_safe(pipefd[READ_FD]);
>> > +//             close_safe(pipefd[READ_FD]);
>> >                 setsid();
>> >                 logfd = open_safe(OLD_LOG_FILE, O_WRONLY | O_APPEND |
>> O_CREAT);
>> >                 dup2_safe(logfd, 1);
>> >
>> > >
>> > > On Tue, Jun 23, 2015 at 11:39 PM, Pavel Emelyanov <
>> xemul at parallels.com> wrote:
>> > >
>> > >     On 06/24/2015 01:42 AM, Ross Boucher wrote:
>> > >     > If I run strace on the docker daemon, criu fails to restore
>> with a
>> > >     different error:
>> > >     >
>> > >     > https://gist.github.com/boucher/bef6e944ae700526a979
>> > >     > (I included both the restore log and the strace)
>> > >     >
>> > >     > Without strace, I get the same fd already in use error.
>> > >
>> > >     Hm... The new error is because criu tries to PTRACE_SEIZE the
>> init to do
>> > >     the
>> > >     --restore-sibling restore and can't do it since strace is already
>> there.
>> > >
>> > >     Can you (for experiment only) patch out the --restore-sibling
>> option from
>> > >     the
>> > >     code that calls criu? Or (!) call criu restore manually on the
>> existing
>> > >     images
>> > >     with all the options being "correct" by yet again w/o the
>> > >     --restore-sibling?
>> > >
>> > >     -- Pavel
>> > >
>> > >
>> > >
>> >
>> > > _______________________________________________
>> > > CRIU mailing list
>> > > CRIU at openvz.org
>> > > https://lists.openvz.org/mailman/listinfo/criu
>> >
>> > _______________________________________________
>> > CRIU mailing list
>> > CRIU at openvz.org
>> > https://lists.openvz.org/mailman/listinfo/criu
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150630/ded3c374/attachment.html>


More information about the CRIU mailing list