[ConsoleKit] extend ConsoleKit to support fast reboot on OpenSolaris x86

[David Zeuthen]

On Wed, Sep 9, 2009 at 10:49 AM, Lennart
Poettering<lennart at poettering.net> wrote:
>> I think the point I was trying to make is that you only want 'slow' if
>> you are trying to debug some oddball problem. Or if your hardware
>> broken (in which case you edit a configuration file that reboot(8)
>> will read so it always select 'slow').
>
> I see it like this: if the user tries to reboot, then probably because
> something is really wrong. If computers and their software were
> without bugs there would not be a reason to manually reboot
> ever. Which is the reason why I think that manually triggered reboot
> shuld always be the 'hardest' reset avaiable.

I don't agree with this. Lots of developers like to reboot their
boxen, for a multitude of reasons, and they shouldn't have to be
forced use the slow path. Also, see below.

> OTOH there are automatically triggered reboots, most importantly after
> a software upgrade. In this case rebooting is not really a choice
> of the user but was asked for by the guy who designed the package that
> was upgraded. Because fast boots are actually much much faster than hard
> resets in this case the user's work should be disrupted only
> minimally, hence a fast reboot is advisable.
>
> Summary: fast reboots are just nicer to the user, so use them wen it
> is safe to use them. Otherwise use full resets.

But I think this logic MUST be implemented in reboot(8) / kexec /
whatever. E.g. leave the task of properly implementing "fall back to
slow reboot if fast reboot doesn't work for whatever reason" [1] to
reboot(8) - if you don't then commandline users of reboot(8) will be
annoyed _anyway_.

[1] : and if fast bool fails,  log this somewhere to spam the user
with a notification next time he logs in - in the spamification, allow
the user to always select "slow boot" - etc etc

> (But then again, I think the whole discussion is not too useful at
> all, since rebooting In my opinion should be handled only be upstart,
> and CK should be out of the game)

Not sure I agree. Rebooting a box is actually much more complicated
than just calling reboot(8). You need to do at least the following
things

 - check that the user is authorized (the needed authorization depends on
   whether there are more than one session)

 - if you have more than one session, you need to play ACK games with other
   sessions otherwise you have data loss: see

    https://fedoraproject.org/wiki/Features/ConsoleKitInhibitAPI

   for more details.

to get it right.

I'm pretty sure I don't want process id 1 to do all this as it's a lot
of code to get right. It's much easier to do in CK because you already
have an in-process representation of the objects you need to deal
with. If Upstart were to do this, it would need to get this
information either via D-Bus or by parsing a file - and it would need
to track changes as the whole process can take many seconds and things
change. That's just a lot of code compared to what you need in
ConsoleKit.

      David