[Pm-utils] Making cron run after resume?

[Stefan Seyfried]

Hi Nigel

(sorry for being late, sometimes i handle my email in batches ;/)

Nigel Cunningham wrote:
> On Sat, 2008-05-17 at 02:05 +0200, Stefan Seyfried wrote:

> I've never properly understood the flow here. I see the gui that lets
> you choose power off/hibernate/suspend etc in Gnome (let's take gnome as
> an example), but I don't know how that gets connected to pm-utils. Is it
> the gui frontend you're talking about? If so, how is one supposed to
> configure it to do the things marked GUI below? Ah, I see. g-p-m etc.
> But they're very limited in the options they provide :\. What I'd like
> to see (and I suspect most users would like this) would be _one_ tool
> (okay, maybe one for Gnome and one for KDE if it has to be that way)
> through which you could configure absolutely everything that's power
> management related.

This would probably not go past the usability-guys who generally seem to think
that users are stupid and giving them options to choose is not an option :(

>>> - unloading modules and refusing to suspend if they can't be unloaded
>> can be done, although a module that cannot be unloaded does not abort suspend.
>> Generally, a module that needs to be unloaded is considered broken and should
>> be fixed in the kernel.
> 
> True, but users tend to be more concerned with what's necessary to get
> things working in the current state of affairs. By all means work
> towards the ideal, but if the software isn't useful with the current
> state of affairs, people are going to hack around it or invent (eg) the
> hibernate script instead.

They can always create a pm-utils hook that blocks suspend if it cannot unload
the module. I'm saying that we (with "we" i mean upstream pm-utils and the
distributions shipping it) should not enable workarounds for kernel bugs
lightly, since it lowers the pressure on the kernel authors to fix their
stuff. One example: the ipw3945 module needs to be unloaded for suspend. I
refused to package this up in pm-utils, instead the hook is in the package
that contains ipw3945.

>>> - umounting and remounting partitions
>> The desktops mount the external devices nowadays - g-p-m, kpowersave or
>> whoever just should tell them to unmount them. This buys you also the ability
>> to do an interaction in the case the external USB stick cannot be unmounted
>> for some reason. This gets very ugly very quick if you want to do it from a
>> script running as root. => GUI
> 
> Mmm, provided the GUI also lets you choose which to unmount.

Well, that's an issue for the GUI. But generally, just "unmount all the
external drives that were automounted by the GUI" is a sane option.

>>> - modifying the grub/lilo menu to help ensure we resume
>>>   for resuming (yes, shouldn't be needed now)
>> I'm doing that already
> 
> Cool. Optional? (Some people hibernate in order to dual boot).

No. I explicitly forbid this with my defaults. People who want that, know what
they are doing and who will then not complain to me about their lost data can
disable the hook that modifies the grub config.
I do not provide an option "Trash all my data" ;)

>> GUI - g-p-m / kpowersave should just tell the desktop to lock the screen.
> 
> Optional? I, for example, don't want the screen locked on resume.

Of course, kpowersave has an option to "lock screen before suspend" which i
also have unchecked (since i use encrypted suspend, i need to enter the
passphrase before resume anyway).

>>> - running arbitrary scripts at arbitrary points in the suspend/resume 
>>>   process (on[suspend|resume] nn command)
>> Use case?
> 
> A means to handle unforeseen needs.

Well, a custom pm-utils hook will do just fine.

>>> - setting the cpu frequency to full speed while hibernating
>> Already done (at least i do it)
> 
> By pm-utils?

yes, pm/hooks/94cpufreq from old pm-utils does that.

>>> - disabling disk write caches
>> why? I'm not against it, i just dont know why it is a good idea ;-)
> 
> This is where I stick up the "I'm no expert" flag. Apparently some
> (older?) drives had problems with getting the data properly flushed
> before we powered off. I don't _think_ this is an issue anymore.

If it is still needed, it can be done in a custom pm-utils hook. It should be
fixed in the kernel however, since it will probably even affect normal system
shutdown.

>>> - muting/pausing audio
>> Why that?
> 
> ALSA mutes devices by default on resume, IIRC.

not for me :-)

>>> - ejecting pcmcia cards
>> Why not fix the drivers?
> 
> This is for users, who don't always know how to fix drivers or have the
> time to fix drivers. While we fix the drivers (or rather while you and I
> handball the problem to the driver author), they want a workaround.

And i have a "45pcmcia" hook in the suse-specific stuff in my pm-utils package
that does exactly that: "pccardctl eject". I have to check if it is still
needed. One could make this a configuration with a variable enabling /
disabling it, if it is needed often.

>> Back then one reason against powersave was the separation of policy and
>> carrying out the actual tasks. Back then i did not really agree, but today i
>> do. Among other reasons because it is really hard to do interactive stuff ("i
>> could not unmount the drive, what do you want to do now?") with another approach.
> 
> Your example is not a separation of policy and implementation, but of
> implementation and user interaction. Ideally, you should be able to get
> the same questions asked if you try to hibernate from init S.

Ideally, yes. But you'd have no UI to display it. And passing "UI components"
from a script running as root up to a user is a PITA. I tried this in
powersaved and it was not funny.

Besides - i don't really see the use case here :-)

>> So today, policy is done by the desktop applet, "mechanics" are done by
>> pm-utils, and i think we should not change that. It makes for a better user
>> experience in the long run.
> 
> I disagree because not everyone wants to run a desktop all the time, or
> at all. Think for example of testing from init S. Use the desktop as one
> means of configuring and initiating an action, but don't make it
> essential to the process.

Well, you can always run "pm-hibernate" as root from the console. And that is
what i recommend to users to debug problems. But then just make sure you
unmounted that external drive first.
In init S it is not automatically mounted - and if you are experienced enough
to do this by hand, you should be experienced enough to unmount it by hand, too.

Basically to keep the efforts at a sane and maintainable level, we probably
need to ignore the more exotic cases. Suspending from init S, at least i
consider it an exotic use case, at least for pm-utils ;)

I mean: NetworkManager (for example) also focuses on the common use cases and
deliberately ignores some setups, which you just need to configure by hand.

I think we should do the same (but it is of course always debatable what is
considered "common" and what is considered "exotic").

Have fun,

	Stefan
-- 
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)