[CRIU] lxc-checkpoint 1.1.5 works with criu 1.6.1 but not master

Adrian Reber adrian at lisas.de
Thu Jan 14 06:46:33 PST 2016


On Thu, Jan 14, 2016 at 05:41:28PM +0300, Pavel Emelyanov wrote:
> On 01/14/2016 03:07 PM, Adrian Reber wrote:
> > On Wed, Jan 13, 2016 at 04:18:31PM +0300, Pavel Emelyanov wrote:
> >> On 01/07/2016 01:04 PM, Adrian Reber wrote:
> >>> Hello Tycho,
> >>>
> >>> thanks for your answers.
> >>>
> >>> On Wed, Jan 06, 2016 at 07:15:25AM -0700, Tycho Andersen wrote:
> >>>> Hi Adrian,
> >>>>
> >>>> On Tue, Jan 05, 2016 at 06:47:55PM +0100, Adrian Reber wrote:
> >>>>> Running lxc-checkpoint works with CRIU 1.6.1 but not with today's
> >>>>> master.
> >>>>>
> >>>>> I get the following dump.log with today's master:
> >>>>>
> >>>>> (00.000250) Probing sock diag modules
> >>>>> (00.000280) Done probing
> >>>>> (00.000283) ========================================
> >>>>> (00.000286) Dumping processes (pid: 10794)
> >>>>> (00.000287) ========================================
> >>>>> (00.000289) Running pre-dump scripts
> >>>>> (00.000315) Found anon-shmem device at 4
> >>>>> (00.000321) Reset 16059's dirty tracking
> >>>>> (00.000329) Warn  (mem.c:56): Can't reset 16059's dirty memory tracker (22)
> >>>>> (00.000341) Unlock network
> >>>>> (00.000347) Unfreezing tasks into 1
> >>>>> (00.000352) Error (cr-dump.c:1578): Dumping FAILED.
> >>>>
> >>>> I've not seen this before. Based on a quick glance through the source,
> >>>> looks like the write() to /proc/pid/clear_refs is failing with EINVAL,
> >>>> which probably means your kernel is too old. Seems like this shouldn't
> >>>> be a fatal failure, though, as lxc-checkpoint doesn't try to use any
> >>>> memory tracking features.
> >>>
> >>> I have always seen the dirty memory tracking warning, but as it is a
> >>> warning it has never been a problem before. It seems, however, that with
> >>> the following commit:
> >>>
> >>> commit d10835c4ee0d0b1881b926708dee9877f5fb294d
> >>> Author: Pavel Emelyanov <xemul at parallels.com>
> >>> Date:   Tue Dec 15 22:25:09 2015 +0300
> >>>
> >>>     dump: Dont read prohibited kernel files
> >>>
> >>> criu now just aborts. Reverting this commits 'fixes' the broken master
> >>> behaviour.
> >>
> >> :(
> >>
> >> Would you check whether the patch titled 
> >> "[PATCH] kdat: Handle pagemaps with zeroed pfns"
> >> from the mailing list fixes it?
> > 
> > Unfortunately not. I had to change the last line of context of that
> > patch to get it applied, but a simple dump still fails:
> > 
> > # ./criu dump -D /tmp/3 -j -t `pidof minimal`  -v -v -v -v
> > (00.000035) Probing sock diag modules
> > (00.000072) Done probing
> > (00.000074) ========================================
> > (00.000076) Dumping processes (pid: 18737)
> > (00.000078) ========================================
> > (00.000081) Running pre-dump scripts
> > (00.000106) Pagemap is fully functional
> > (00.000136) Found anon-shmem device at 4
> > (00.000141) Reset 20624's dirty tracking
> > (00.000147) Warn  (mem.c:56): Can't reset 20624's dirty memory tracker (22)
> 
> Hm... Does your kernel lack support for soft-dirty tracking at all?

Yes. No soft-dirty tracking for me. But that was no problem until now.

		Adrian


More information about the CRIU mailing list