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

[Hans de Goede]

Hi,

On 6/30/20 11:36 AM, Lennart Poettering wrote:
> On Mo, 29.06.20 11:02, Hans de Goede (hdegoede at redhat.com) wrote:
> 
>> Hi All,
>>
>> For Fedora 33 I would like to get rid of some ugly hacks we have
>> wrt the grub-hidden-menu feature Fedora has been shipping for a
>> while now.
>>
>> One part of this will be setting SYSTEMD_REBOOT_TO_BOOT_LOADER_ENTRY
>> in logind's environment, and add /run/systemd/reboot-to-boot-loader-menu
>> support to the Fedora grub-packages (the hidden-boot-menu stuff is
>> not in upstream grub yet) and make GNOME use the dbus protocol to
>> request rebooting into the boot menu.
>>
>> Another, harder part is boot-success or in systemd terms boot-complete
>> support. ATM the Fedora GNOME packages contain a downstream patch
>> which directly invokes "grub2-set-bootflag boot success". The plan
>> is to have a grub2-bless-boot.service which will be a copy of
>> systemd-bless-boot.service which will do grub's equivalent of
>> calling /usr/lib/systemd/systemd-bless-boot good  (we do not
>> want automatic-boot-assesment, we just want the menu to show or
>> not show on the next boot). This bit is east too.
>>
>> The tricky part is having grub2-bless-boot.service not run until
>> GNOME says that it is ok. The thinking behind this (and current
>> behavior) is that even if everything looks ok from the all services
>> are running pov, then things might still be wrong. E.g. the kbd
>> and mouse could be non-functional leaving the user with a
>> non-functional system. So we only want to mark the boot successful
>> after:
>>
>> 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.

Currently for "boot-success" marking we rely on confirmation
of successful interaction with the user (so working gfx output
+ kbd + mouse) and we want to keep doing that.

If we remove the timeout from your proposal then it should work fine
though.

So I think we agree on needing a tiny service for this, which
gets contacted by the GNOME session when the GNOME session
considers the boot successful. The main difference between
our proposals seems to be that I want to add the service to
the boot-complete.target and you suggest adding it to the
usual boot process, which I assume would be multi-user.target.

To me adding it to boot-complete.target feels like it makes
more sense, since the whole purpose of the mini service is
just to delay boot-blessing, and AFAIK that is exactly what
boot-complete.target is for ?

Regards,

Hans