[systemd-devel] GNOME boot-complete.target integration ?

[Lennart Poettering]

On Di, 30.06.20 12:17, Hans de Goede (hdegoede at redhat.com) wrote:

> > > 1. The user has logged in successfully and the session lasts
> > > at least 2 minutes (could be a bit shorter, we want to catch the
> > > case where the session immediately exits / crashes after login); or
> > >
> > > 2. The user selects reboot/shutdown from the GNOME system-control
> > > menu.
> > >
> > > In both these cases we want to block the boot-complete.target
> > > from being considered finished/ready until GNOME says it is.
> > >
> > > I can easily achieve this by not adding the grub2-bless-boot.service
> > > to any targets, and then manually starting it (with a polkit rule to
> > > allow a regular user to do this) when either condition becomes true,
> > > but then I still have the GNOME code doing something grub (Fedora's
> > > grub even) specific. So what I really want to do is delay the
> > > the boot-complete.target from being considered finished/ready until
> > > GNOME says it is.
> > >
> > > So the question really is, is there a way to have a unit wait with
> > > starting until a certain event happens?
> > >
> > > I guess I could use a Oneshot type service and have a little helper app
> > > which waits until it is signalled that the boot is complete? Any other
> > > ideas?
> >
> > Why not have a tiny service that is started as part of boot. It hangs
> > around for 2min or, and then exits with failure. If however it is
> > contacted by D-Bus before that it exist immediately with
> > success. Then, make GNOME just ping that service if all is good.
> >
> > The service would then become part of the usual boot process, ordered
> > before the boot blessing.
> >
> > Wouldn#t that suffice?
>
> That will break in the following scenario:
>
> 1. User powers on the machine goes to grab coffee
> 2. User returns after 5 min. logs in and goes to work
>
> Notice that the contacting by DBUS you suggest would not happen
> until after 2, at which point the timeout has happened.

So on the low level we actually have a concept for marking a boot as
"neutral", but I think we only expose that in sd-boot, and
badly. i.e. the idea is that a boot can be considered "bad", "good" or
"neutral". I guess we could model things for you so that initially the
boot is marked as "bad", up to the point where gdm decides it
managed to start up. In that case we'd mark things as "neutral". As
soon as gdm then received user input so that the log in starts, it
would mark things as "bad" again. And when GNOME in the user's session
finally is done with everything we'd mark things as "good" and
everything is complete.

>From a boot loader that boots up and finds the boot success state as
"bad" it will increment the fail counter of the boot item. If it finds
it as "good" it will mark the boot item as "good" forever.  But if it
finds it in "neutral" it will do neither.

Such a logic would work for you, right?

Lennart

--
Lennart Poettering, Berlin