Lennart Poettering wrote:
You can actually use systemd.confirm_spawn=yes on the kernel
cmdline. This should work fine for an interactive boot and things are
synchronized via tty ownership. However, I am not sure how useful this
all is, given that we starte gdm pretty early (which then owns the
console tty and hence makes it impossible to ask any further questions
which then timeout) and this options asks a confirmation question for
*everything* we start, not just sysv services. That means you get even
asked on shutdown, and when we activate bus services.
systemd.confirm_spawn=yes is a debugging tool, but I don't think this is
useful for a broader audience or ever could be made useful for a broader
I don't see these as unsolvable problems:
* Starting prefdm or gettys can be delayed when using interactive boot.
* It can just stop asking for confirmation after a certain target is
reached, e.g. after prefdm or gettys is started.
One possible implementation would be to have an EndsInteractiveBoot target
property. When that is set to yes, which it would be for prefdm and gettys,
systemd should 1. try to execute it "as late as possible", i.e. only when
there are no other pending changes not depending on that target and 2. stop
confirmation prompts after starting that service is confirmed.
Another question is whether we need to ask for confirmation for items which
don't normally block booting in the first place. If such items hang, they
can just be killed by the user.
Unless we introduce some kind of interactive UI that somehow
clash with gettys or gdm being active on a tty I don't hink we can ever
make interactive boots work again.
Wasn't one of the points of KMS to be able to switch a console to text mode
at any time? That said, getting dropped back to text mode from my KDE to
confirm activating some service probably isn't useful (see also my note
above about non-blocking items).