On Thu, 20 Dec 2007 16:35:06 +0100
Juan RP <juan@xtrarom.org> wrote:

> On Thu, 20 Dec 2007 10:16:07 -0500
> "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
> 
> > There's kernel code that does it, too; before the fix was developed
> > -- as you and others have noted, this is code that is improving very
> > rapidly -- I experienced a power-down while in single-user mode.
> > (Aside: there really needs to be a sysctl controlling what
> > happens.  I, for example, would prefer a suspend.)
> 
> powerd(8) has all the information.
> 
> You experienced a power-down unexpectedly because acpiec(4) wasn't
> providing correct data. And I don't agree with your suggestion,
> because if you suspend it while the system is in low power, there
> will be the same issue... the battery will be finally discharged.
> 
> Anyway, if you want this feature feel free to provide a patch or use
> powerd(8) and change the default action in the 'low-power' event.
> 
> The code we have currently avoids losing data or fscks, so you at
> least don't waste extra time after booting a system that was out of
> battery.
> 
I'll reply once to all three of you...

You need *some* power for suspend.  It's also why I do a sync in
the suspend process, though I believe the current ACPI code does
that automatically.  The problem that shutdown loses application
data.  If I'm editing a file, I want time to save it.  In other
words, while clean shutdowns of file systems are important, clean
shutdowns of applications are important, too.  (The shutdown command
in powerd/scripts/sensor_battery *really* needs to do a 'shutdown
+5' instead of a 'shutdown now'.  However, it probably needs an &
after it, since it appears from other interactions -- I haven't
checked this thoroughly -- that powerd blocks waiting for scripts
to finish.  There also needs to be an easy way to cancel the
shutdown.  Often, for example, I'm working in a comfortable chair
and don't want to bother dragging out the power adapter.  When I
get the "your battery is really, really low" warning, I either
suspend and move to my office or I do go to the trouble of finding
the power cord...    Either way, I need to cancel the shutdown.)

Beyond that, it isn't clear to me that the criteria for a low-power
event are correct.  The comments in sensor_battery (and I think in
the kernel) suggest that the event happens when the batteries are
in either the LOW or CRITICAL state.  Perhaps suspend (after warning)
on LOW, and shut down on CRITICAL?  (Yes, I had problems because
of bugs, since resolved, in acpiec.  I'm treating that more as an
early, inadvertent exposure to the user interface...)

I would like to separate the kernel issue from the powerd scripts.
If I'm in single user mode, I'd really better know what I'm doing,
and it's not the kernel's job to make certain decisions for me.

The userlevel issue is much more complex.  Apart from the shutdown
vs.  suspend issue, there's the problem of user notification (do
gnome or kde users tend to have shell windows open?) and response.

You're right, of course, that I should send code.  I'll do that.
For the kernel, I propose a sysctl -- machdep.acpi_lowbattery is
my suggestion -- whose value in [0:3] selects among shutdown,
suspend, warn, nothing, with the default being today's behavior
(shutdown).

The userlevel situation is more complex, and I suspect that we need
different UIs for the X/non-X cases.  To me, at least, the principles
are clear:

	(a) administrator choice of action -- you like shutdown
	and I like suspend, for example.

	(b) a warning to the user of at least a couple of minutes
	before the action is executed.

	(c) the ability to cancel a pending action easily, for use
	by the user, a GUI on behalf of the user, or powerd if the
	situation changes (i.e., if the power adapter is plugged
	in during the warning period.  I'll be working on code for
	this, too, though it will take longer since the proper shape
	of the solution isn't clear to me.

	(d) it is reasonable for the more complex X-based interface
	to live in pkgsrc (and depend on other pieces of pkgsrc),
	especially since many people are running modular Xorg
	anyway.

Comments, especially these design principles?


		--Steve Bellovin, http://www.cs.columbia.edu/~smb