Bug#799329: sysvinit: does not work inside systemd-nspawn

[Jonathan de Boyne Pollard]

Dmitry Bogatov:

> Can we expect you [Andreas Henriksson] to provide necessary lines in 
> /etc/inittab?
>

Xe will have some difficulty doing that completely.  The systemd 
protocol for such containers is to have a fixed TUI login service on 
/dev/console (as already mentioned) and *also* dynamically-started TUI 
login services on all of the terminals named in the value of the 
"container_ttys" environment variable inherited by process 1.  That 
latter does not really map well to /etc/inittab , which does not really 
have the mechanism for dynamically starting/stopping records in the table.

* https://freedesktop.org/wiki/Software/systemd/ContainerInterface/

That said, I suspect that people are going to hit difficulties marrying 
the "container_ttys" model to the new multiple-instance way of using 
devpts in the long run, and the latter will cause the former to be 
unused.  Which leaves *just* the problem of having a TUI login service 
on /dev/console and turning off the TUI login services on the 
non-existent other terminals.  I don't see any way to do this in a way 
that provides something that functions ab initio without the 
administrator intervention of editing the file, without simply having 
different /etc/inittab files.  This sort of dynamic starting of TUI 
login services simply hits the limits of the /etc/inittab model; and 
always has, as demonstrated by the fact that almost every augmentation 
or replacement over the decades from the SAF onwards has taken the 
configuration of TUI login services out of /etc/inittab's hands and into 
the hands of something with service start/stop flags.  (-: