[CRIU] [PATCH 0/5] tty: Use reg-files engine to save paths to tty peers

Cyrill Gorcunov gorcunov at gmail.com
Mon Oct 13 10:27:25 PDT 2014


On Mon, Oct 13, 2014 at 11:58:32AM -0500, Tycho Andersen wrote:
> On Mon, Oct 13, 2014 at 08:57:23PM +0400, Cyrill Gorcunov wrote:
> > On Mon, Oct 13, 2014 at 11:37:33AM -0500, Tycho Andersen wrote:
> > > Hi Cyrill,
> > > 
> > > On Mon, Oct 13, 2014 at 07:51:47PM +0400, Cyrill Gorcunov wrote:
> > > > Hopefully this time all issues are addressed. Please take a look.
> > > > Once series get merged I'll implement /dev/console support.
> > > 
> > > When I try with this patchset on a container that has been restored
> > > (i.e. the case that failed last time with the ioctl error), I now get:
> > > 
> > > (00.259398) Error (files-ext.c:91): Can't dump file 0 of that type [20660] (chr 5:1)
> > > 
> > > I guess this is related to the underlying problem? Actually I don't
> > > understand how criu can restore ttys, doesn't something else have to
> > > set them up and tell criu that they were bind mounted correctly?
> > 
> > 5:1 is /dev/console ;) It's not yet addressed, I'll do it on top once
> > series is merged.
> 
> Ah, I see. That's what was failing for me before (with the bad ioctl
> message), so maybe this will clear up handling of that problem to
> then.

Yeah. You know, the main problem here is not /dev/console as itself
(which is unsupported at moment and expected to fail) -- the main
problem is that I don't understand how restored pty peer became
console on second checkpoint pass. I guess it was changed to this
type by some probgram either inside container itself, or some daemon
outside of the container.


More information about the CRIU mailing list