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

[Serge Hallyn]

Quoting Cyrill Gorcunov (gorcunov at gmail.com):
> 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.

So Tycho, when you start the container first, /dev/console is 136:N
(N=34 or something).  When you restart it the first time, what is
/dev/console?

-serge