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