[Pm-utils] [PATCH 1/6] Split hook running into two phases -- core and aux

[Stefan Seyfried]

Dan Nicholson wrote:
> Hi Victor,
> 
> On Sun, May 11, 2008 at 6:43 PM, Victor Lowther
> <victor.lowther at gmail.com> wrote:
>> Core phase is for hooks that work around software or hardware quirks
>> that may cause the system to not suspend correctly. Hooks will automatically
>> fall into this category if their filenames start with at least two digits.
>>
>> Aux phase is for programs that want to do something when the system suspends
>> or resumes, but that do not need to run in any particular order or whose
>> success or failure has no bearing on whether or not the suspend/resume
>> process should fail.
> 
> I would really prefer that we just tighten the specs on hooks instead
> of getting creative with what hooks run when and whose errors are
> critical.

Full ACK.

> In my mind, the hooks should work like this:
> 
> 1. Hooks are run in lexicographical order on suspend and reversed on
> resume. If your hook depends on running early or late, name it so that
> it sits at an appropriate place in the order. Maybe a restriction that
> it must begin with two digits, in which case, 50$hookname if you don't
> care when it runs.

Again, full ACK from me.

> 2. Failures from hooks always result in suspend or resume errors. If
> the hook has non-critical errors, then it should return 0, full stop.
> If someone doesn't have bluetooth or NetworkManager or ntpd isn't
> running, that should not be considered a critical error. I don't
> consider alsactl failing to be worth more than a warning in the logs,
> but I think the better way to handle this is the hook not returning a
> failure, not marking the hook as some sort of special case.

Until now, we just created $INHIBIT, possibly even with descriptive content
what failed and why we cannot suspend because of it, and thus had no need to
care for the return code. Just check if $INHIBIT is created at the end of the
hook-running code and then refuse to suspend and return from
pm-{suspend,hibernate} with an exit code != 0.
The GUI app can show the user the logfile and the content of the $INHIBIT file.
This is not a perfect solution, but a reasonably simple one and then we should
try to avoid failing suspends anyway ;-)

> That's how I see it, anyway. I think we can just make the current
> hooks more robust rather than re-implement the hooks structure. If
> there are hooks we're distributing that are difficult to get right,
> then let's not install them by default. Distros can add or remove the
> hooks as apply to their system.

Absolutely. Keep it simple. Remember that there are people that might need to
write hooks but do not want to read a complicated spec (or are just not able
to understand it ;), just to understand what they need to do for a trivial task.
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)