Re: systemd acceptance, packaging guidelines (was Re: systemd and changes)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux