[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 00:20:45 PDT 2014


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: -

Is this the sort of thing that might be leftover from a previous bad restore?

Tycho


More information about the CRIU mailing list