disabling sleep when shutting down

[Ian Smith]

On Thu, 17 Sep 2015 16:22:55 -0700, Colin Percival wrote:
 > On 09/17/15 14:39, Dan Lukes wrote:
 > > Colin Percival wrote:
 > >> I considered that option but thought that disabling suspend completely
 > >> would be better in case it was triggered by something else
 > > 
 > > You has been affected by LID issue - and here I'm with you.
 > 
 > Ok.  But adjusting the sysctl might not be enough; KDE has a "suspend
 > when lid closed" setting which seems to be broken right now, but if it
 > worked we would need to figure out how to disable that as well.

If our KDE isn't using FreeBSD methods to manage suspend and/or shutdown 
(given it's generally pretty linux-centric), presumably acpiconf -S{3,5} 
or in the case of shutdown, perhaps invoking 'shutdown -p now [message]' 
then that's a separate issue that needs fixing in KDE.  I wouldn't even 
consider trawling through KDE power management code, if I could find it.

I think Dan's right, deal with the LID issue by disabling suspend-on-lid 
in shutdown.c, which needs adding a sysctl handler for it, and just set 
it to 'NONE' after validating options etc.  This won't need to consider 
any of the other possible circumstances, just disabling a convenience.

And then there's what type of shutdown has been issued?  -p powerdown? 
-r reboot?  -h halt?  No switches to drop to single user?  With any 
delay, or 'now'?

And there's the chance that someone has set hw.acpi.disable_on_reboot .. 
things could get messy, but early disabling of hw.acpi.lid_switch_state 
sounds pretty safe to me, and you can see by LEDs if the system hasn't 
suspended after closing the lid, or whether it's shut down, or rebooted.

 > > Suspend triggered by exhausted battery case needs to be evaluated
 > > carefully. Battery may be so exhausted so shutdown will not be
 > > completed. Note that some system (hardware) require no power to maintain
 > > suspend context, thus suspend may save system.

My X200 runs for something like a week suspended from full charge, but I 
do miss the control APM offered, running scripts at every 10% graduation 
and on critical low power, charging or discharging.  I've managed to get 
devd to run a script on CMBAT events that logs (among other things) the 
battery state via acpiconf -i0.  The X200 does so on power loss/returned 
and at 80% and 20%, charging or discharging, but I've yet to add code to 
parse those looking for capacity less than say 10% to invoke suspend, or 
critical low power to invoke shutdown, but it's functionality I'd like.

 > > And what about other reasons for suspends ? I can tell nothing about all
 > > those cases. Suspend may be triggered for any reason, thus so many
 > > possible causes. I can't claim all of them are illegitimate and can be
 > > safely ignored. I wish we should have stronger reason for system global
 > > behavior change than just feeling (no offense!).
 > 
 > The example of a system which can usefully suspend but doesn't have enough
 > battery life left to allow it to complete a normal shutdown seems a bit
 > implausible, but I'll concede that it's theoretically possible.  Maybe we
 > should have an rc.d script which checks an rc.conf setting?

Well I think this has shown there are plenty of possible conditions to 
consider and possible races to avoid, going down that path.  Disabling 
hw.acpi.lid_switch_state would seem to solve your original problem 
without needing to mess with ACPI, until such scenarios are examined?

cheers, Ian