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
> audience.
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 doesn't
> 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).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
