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

[Cyrill Gorcunov]

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.