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

[Cyrill Gorcunov]

On Tue, Oct 14, 2014 at 12:43:26PM +0000, Serge Hallyn wrote:
> Quoting Cyrill Gorcunov (gorcunov at gmail.com):
> > On Tue, Oct 14, 2014 at 04:06:14AM -0500, Tycho Andersen wrote:
> > > > > > 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.
> > 
> > Yes, it is not yet addressed. /dev/console is special, it's rather a wrapper
> > over real driver (usually one of vt peer, or can be anything else console
> > laying underneath).
> > 
> > It get dumped first time fine simply because I think it was not opened
> > inside container. The dumps you've been sending to me shown that
> > 
> > id: 0x1 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x502 pty: { index: 0 }  
> > id: 0x3 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x502 pty: { index: 0x1 }  
> > id: 0x5 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x502 pty: { index: 0x2 }  
> > id: 0x7 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x502 pty: { index: 0x3 }  
> > id: 0x9 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x502 pty: { index: 0x4 }  
> > id: 0 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x8800  pty: { index: 0 }  
> > id: 0x2 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x8801 pty: { index: 0x1 }  
> > id: 0x4 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x8802 pty: { index: 0x2 }  
> > id: 0x6 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x8803 pty: { index: 0x3 }  
> > id: 0x8 type: PTY locked: False exclusive: False packet_mode: False sid: 0 pgrp: 0 rdev: 0x8804 pty: { index: 0x4 }  
> > 
> > see -- you've 5,2 devices (which are master PTY peers) and then a bunch of appropriate slave peers.
> > So they are dumped fine and restored as well, but then on second checkpoint criu finds that there is /dev/console
> > opened for some reason and of course can't work with it since there is no such support yet.
> 
> So what has opened it, and why?  Tycho can you tell from your dump images?

After the first restore but before second checkpoint /dev/console has been opened for some reason and
we've failed to dumped such configuration.