[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 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?