[CRIU] [PATCH 0/5] tty: Use reg-files engine to save paths to tty peers
Tycho Andersen
tycho.andersen at canonical.com
Tue Oct 14 02:06:14 PDT 2014
On Tue, Oct 14, 2014 at 09:03:08AM +0000, Serge Hallyn wrote:
> Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > On Mon, Oct 13, 2014 at 07:57:41PM +0000, Serge Hallyn wrote:
> > > 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?
> >
> > Perhaps that is part of the problem, with
> >
> > lxc.console = none
> > lxc.tty = 0
> >
> > in my config, when I boot the container normally, /dev/console is:
> >
> > ubuntu at u1:~$ stat /dev/console
> > File: ‘/dev/console’
> > Size: 0 Blocks: 0 IO Block: 4096 character special file
> > Device: fd01h/64769d Inode: 133996 Links: 1 Device type: 5,1
> > Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 5/ tty)
> > Access: 2014-10-14 07:17:47.758239000 +0000
> > Modify: 2014-10-14 07:17:47.758239000 +0000
> > Change: 2014-10-14 07:19:58.995254999 +0000
> > Birth: -
>
> Aah, of course! So /dev/console is 5:1 from the start for you. Given that
> Cyrill is working on pty support, can you now change that? :)
Not exactly, /dev/console support still isn't there with this
patchset. The part I'm confused about is that this 5:1 device dumps
fine the first time, but then doesn't the second time.
Tycho
More information about the CRIU
mailing list