[Pm-utils] Making cron run after resume?

[Nigel Cunningham]

Hi again!

On Sat, 2008-05-17 at 02:05 +0200, Stefan Seyfried wrote:
> Hi Nigel,
> 
> Nigel Cunningham wrote:
> 
> > I like the simplicity argument, but I have to admit at the same time
> > that I'd like to see pm-utils catch up to the hibernate script in terms
> > of functionality. The hibernate script has support for:
> 
> Lots of those are out of scope for pm-utils, since they should / can be done
> easier from the GUI frontend that calls pm-utils via HAL, i'll go through the
> list and just mark them as "GUI".

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.

> > - 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.

> With the start of pm-utils, we wanted to get out of the workaround business,
> and into the bugfixing business (i was too long in the workaround business
> with the old powersaved ;)

(See above :>)

> > - stopping, starting and restarting services
> 
> Can be done, just a hook that does stop / start the service. However, for most
> services the same applies as with modules: they should be made suspend-aware.
> There are exceptions though, but those packages can deliver the hook to
> stop/start the service. Infrastructure for such hooks is already in pm-utils.

k.

> > - 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.

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

> > - running vga tools
> 
> done already
> 
> > - X screensaver locking
> 
> 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.

> > - running arbitrary scripts at arbitrary points in the suspend/resume 
> >   process (on[suspend|resume] nn command)
> 
> Use case?

A means to handle unforeseen needs.

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

By pm-utils?

> > - setting the various tuxonice options via a generic
> > 	'procsetting file_name value'
> >   interface. (Yeah, it's not /proc anymore)
> 
> This should be done in the tuxonice module

Right.

> > - 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.

> > - taking down and bringing back up network interfaces
> 
> GUI => g-p-m should just tell nm-applet to bring down the network (which in
> turn will eventually tell Thunderbird to stopp fetching mails etc).
> 
> > - muting/pausing audio
> 
> Why that?

ALSA mutes devices by default on resume, IIRC.

> > - 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.

> > - refusing to suspend/hibernate if particular programs are running
> 
> The desktop should already have an inhibition mechanism where programs can
> request that no suspend happens if they are running (Richard surely knows more
> about that topic).
> 
> > - getting gaim to logout/restore status etc
> 
> GUI => see above about network
> 
> > I'm not an expert on how the script works (I didn't write it), but I
> > know it uses scriptlets that register hooks to make this all happen
> > without being (too?) ugly.
> 
> And all the ugly stuff is in the scriptlets then? ;-)

:) I've done some work on the suspend2 scriptlet, and it looks quite
neat and tidy actually.

> pm-utils is designed to work together with HAL and a desktop application
> (g-p-m or kpowersave) which is sufficiently intelligent to only tell HAL to
> suspend the system if the prerequisites are fulfilled:
> - external drives are unmounted
> - network is brought down, before that, network applications are notified and
> given a chance to finish their work
> - nobody raised a complaint about suspend (cd-burning program,...)
> - screen is locked
> - ...
> 
> 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.

> 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.

Regards,

Nigel