CK: more paranoia, idle status, and creation-time
William Jon McCann
mccann at jhu.edu
Wed Mar 7 14:04:43 PST 2007
On 3/7/07, Richard Hughes <hughsient at gmail.com> wrote:
> g-p-m is per session, and so stuff like yum run as root can't Inhibit
> the system. And inhibiting the system via a session daemon breaks
> horribly when you do fast user-switching.
>
> So, given ConsoleKit is a daemon watching for activity on consoles, what
> about adding a Inhibit interface to it and removing the interface from
> g-p-m?
Here's the way I see it at the moment.
I'm sitting at a computer using a seat that has permission to make
decisions related to powering it off. I'm on the active session for
that seat. I should be able to power the system down explicitly at
any time. If I close my laptop at any time it should suspend - no
matter what. And if it can't suspend - it should sound a loud warning
so I won't shove it in my bag. That means that at least in the
default case we shouldn't have any "hard" inhibitors. If I lose a CDR
in the process - my bad. If I suspend while yum is running - oh well
it needs to handle that.
If it is an explicit request where we still have access to the
requestor (ie. an interactive request) we should probably:
a) ask the user if pending tasks should be interrupted (ie. killing yum)
b) warn the user if there are other sessions running on the system
On the other hand, for the case where g-p-m is trying to power
down/suspend due to inactivity then it should probably:
a) check its inhibitors and continue silently if any are present
b) look for other sessions on the system and ask the user if the
action should proceed
I'm talking about the default case here. There should probably be a
way for sysadmins to lock all this down.
For the yum running outside of a normal session case. Presumably
something is running yum. It may be a user (eg root) or cron etc. If
the user opened a session with CK then the above logic would already
handle this. cron already uses PAM to open a session from what I can
tell.
Did I effectively avoid your question? ;)
Jon
More information about the hal
mailing list