This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 427018 - allow disabling of pm-hibernate and pm-suspend without running quirks
allow disabling of pm-hibernate and pm-suspend without running quirks
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pm-utils (Show other bugs)
12
All Linux
low Severity low
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
FutureFeature
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-29 20:41 EST by Michal Jaegermann
Modified: 2010-12-05 02:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 02:13:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
a trace from a run 'sh -x /usr/sbin/pm-suspend' (1.22 KB, text/plain)
2007-12-29 20:41 EST, Michal Jaegermann
no flags Details
/var/tmp/suspend.log from the run above (6.54 KB, text/plain)
2007-12-29 20:42 EST, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2007-12-29 20:41:54 EST
Description of problem:

Let say that we have a machine on which, for whatever reasons, we
want to prevent ever trying suspening and hybernating.  This is
not documented, so there is no way to tell what is supposed to be
a correct behaviour, but lines
DISABLE_HIBERNATE="no"
DISABLE_SUSPEND="no"
from 
/usr/lib/pm-utils/defaults suggest that changing those values should
help with the goal.  So I created /etc/pm/config.d/disable where
those two variables are set to "yes".  This does not help very
much as hooks are run and at this moment everything is dead.
A trace from 'sh -x /usr/sbin/pm-suspend is attached and
/var/log/pm-suspend.log produced that way.

With the following change in /usr/lib/pm-utils/functions those
utilities are really disabled.

--- functions.orig      2007-10-23 14:25:27.000000000 -0600
+++ functions   2007-12-29 18:18:18.000000000 -0700
@@ -140,6 +140,9 @@

 pm_main()
 {
+       [ "$1" = suspend -a "$DISABLE_SUSPEND" != "no" ] && return 0
+       [ "$1" = hibernate -a "$DISABLE_HIBERNATE" != "no" ] && return 0
+
        if [ -n "$PM_LOGFILE" ]; then
                exec > "$PM_LOGFILE" 2>&1
        fi

Version-Release number of selected component (if applicable):
pm-utils-0.99.4-6.fc8
Comment 1 Michal Jaegermann 2007-12-29 20:41:54 EST
Created attachment 290540 [details]
a trace from a run 'sh -x /usr/sbin/pm-suspend'
Comment 2 Michal Jaegermann 2007-12-29 20:42:55 EST
Created attachment 290541 [details]
/var/tmp/suspend.log from the run above
Comment 3 Till Maas 2007-12-30 14:34:09 EST
(In reply to comment #0)
> Description of problem:
> 
> Let say that we have a machine on which, for whatever reasons, we
> want to prevent ever trying suspening and hybernating.  This is
> not documented, so there is no way to tell what is supposed to be
> a correct behaviour, but lines

In this case, either the kernel should not create /sys/power/{disk,state} or it
should be handled via hal-info.

> DISABLE_HIBERNATE="no"
> DISABLE_SUSPEND="no"
> from 
> /usr/lib/pm-utils/defaults suggest that changing those values should
> help with the goal.  So I created /etc/pm/config.d/disable where
> those two variables are set to "yes".  This does not help very
> much as hooks are run and at this moment everything is dead.

I am not sure, whether I really read it somewhere, but it would also explain the
current beheaviour: The variables are only used for internal purposes, i.e.
testing pm-utils, without really suspending the machine.

Do you have a machine where suspend should be disbled or is this only a
theoretical problem?
Comment 4 Michal Jaegermann 2007-12-30 18:38:36 EST
> In this case, either the kernel should not create /sys/power/{disk,state}

Well, why not?  I theory a machine is capable of doing both only
attempts to use those capabilities end up with a blank screen,
no responses whatsover anywhere and a need for a power switch does
not matter which quirks you are trying.  BTW - pm-suspend has 10
such quirks so systematically check all of them is 1024 combinations.
A little bit much, even if in practice this number can be reduced,
taking into account that each failed attempt ends up in a crash.
Unfortunately I have seen that too many times and updates can
reduce a machine which used to suspend to something which it is
not doing that anymore and other nasties.  This is so fragile ...

> or it should be handled via hal-info.

Fine!  How and where is this documented?  Some bits and pieces
on scattered web sites, which one to has find by strange searches
and which most often do not say anything substantial, do not qualify.

> I am not sure, whether I really read it somewhere, but it would
> also explain the current beheaviour: The variables are only used
> for internal purposes.

There is a need to be able to turn off suspend and hibernate so
even mistaken runs caused by a click on a wrong button will not
do any harm.

The most recent particular case is Fedora 8 running on Asus EeePC
from an SD card inserted in a slot of that machine.  For "hibernate"
there is simply not enough space on that "disk" to be able to write
there a corresponding image.  So this is immediately out although
OS cannot "know" that by itself.

Attempts to suspend using hal mechanisms, does not matter which way
and with what quirks, invariably end up as noted above with _zero_
information from failed attempts - which is usually the case.  It turns
out that with appropriate hacks and using a suspend script written
specifically for the sitation I can recover from a suspension as
far as to get back a video an a network.  A this moment I hit a snag.
File systems are accessed via USB and apparently to get USB working
I need and access to files; so I end up with none and a shell reduced
to builtins.  This is waaay far I ever achieved through hal and pm-utils.
So far do not know how to work around that snag. Busybox and some 
stash in memory and/or a special ramdisk?  At least for now that
operation is non-functional, and via "official means" much less so,
so I need to turn that off.

If pm-utils and hal provide that level of control, in a way which is
obvious, easy to use, does not leave me guessing what happened behind
my back and will not get clobbered by updates, then I am all ears.
A non-documentation obviously does not help here very much.  For now
I have at least to disarm that heap.
Comment 5 Till Maas 2007-12-30 19:31:06 EST
(In reply to comment #4)
> > In this case, either the kernel should not create /sys/power/{disk,state}
> 
> Well, why not?  I theory a machine is capable of doing both only
> attempts to use those capabilities end up with a blank screen,
> no responses whatsover anywhere and a need for a power switch does
> not matter which quirks you are trying.  BTW - pm-suspend has 10
> such quirks so systematically check all of them is 1024 combinations.

The quirks are mostly/only there to get the video output working after suspend
and afaik there is no notebook in the hal-info or swsuspend whitelist, that
needs more than 4 quirks.

> > or it should be handled via hal-info.
> 
> Fine!  How and where is this documented?  Some bits and pieces
> on scattered web sites, which one to has find by strange searches
> and which most often do not say anything substantial, do not qualify.

You need to persuade the hal developers to add an item for this in the hal
database, e.g. power_management.should_not_suspend and
power_management.should_not_hibernate. Then e.g. the gnome-power-manager can
query this.
 
> The most recent particular case is Fedora 8 running on Asus EeePC
> from an SD card inserted in a slot of that machine.  For "hibernate"
> there is simply not enough space on that "disk" to be able to write
> there a corresponding image.  So this is immediately out although
> OS cannot "know" that by itself.

This can happen on a normal notebook, too. Afaik nothing bad should happen, when
hibernation fails because of too little free space. I do not know, whether the
EeePC does not support such big SD cards, but there are at least 16GB big SD
cards available, there hibernation should be possible.

> Attempts to suspend using hal mechanisms, does not matter which way
> and with what quirks, invariably end up as noted above with _zero_
> information from failed attempts - which is usually the case.  It turns

In case you do not know, pm-utils logs to /var/log/pm-suspend.log, maybe there
is some useful information.

> If pm-utils and hal provide that level of control, in a way which is
> obvious, easy to use, does not leave me guessing what happened behind
> my back and will not get clobbered by updates, then I am all ears.
> A non-documentation obviously does not help here very much.  For now
> I have at least to disarm that heap.

Btw. maybe for your case it is also enough to just put a file in
/etc/pm/config.d that contains only an exit 1, e.g. with
echo "exit 1" >> /etc/pm/config.d/00-disable

Then pm-utils will not do anything harmful.
Comment 6 Michal Jaegermann 2007-12-30 20:12:02 EST
> afaik there is no notebook in the hal-info or swsuspend whitelist, that
> needs more than 4 quirks.

Oh, great!  So this reduces a number of crashes to only 386 before
we discovered that we need that fifth quirk. :-)  I am pulling your leg,
of course, but if you do not have other info this is a very frustrating
process.

> You need to persuade the hal developers ...

My success rate in persuading the hal developers about anything
is so far around zero and attempts to do so left me with a very
bad taste in my mouth.  I doubt if I will ever try again.

(about no or too small swap):
> This can happen on a normal notebook, too. Afaik nothing bad should happen

Maybe.  I tried to see what effects will be.  On recent attempts
always the same - black screen and a locked up machine regardless
of options.  In the past some messages were printed on a screen
at least giving me some clues how far I got before things went
haywire so where possibly to look.  Now I am literally kept in
the dark.  Indeed "nothing bad" happened in that sense that I was
alway able to boot after powering down.  Still not that exciting.

> In case you do not know, pm-utils logs to /var/log/pm-suspend.log

There is a sample /var/log/pm-suspend.log attached to the original
report so probably I am aware of its existence.  Not that I learned
much from there.  OK, so maybe I should peek into it more often ...
OTOH I am not that convinced that I should learn about it from
reading scripts in 'pm-utils'.

That particular case of EeePC and an SD card possibly makes that even
less informative as file systems go away before whatever buffered
was flushed into log.

> Btw. maybe for your case it is also enough to just put a file in
> /etc/pm/config.d

That is precisely what I was trying to do but you are telling
me that "DISABLE_..." really means something else. :-)  Yes, I would
prefer to learn that from some docs instead of bugging you.
Comment 7 Till Maas 2008-01-08 12:08:21 EST
Btw. suspend and hibernate seems to work for the eeepc sometimes according to
http://code.google.com/p/eee-ubuntu-support/

In acpi/etc/default/acpi-support in their tarball you find some hints on how to
enable suspend/resume for the eeepc, but sadly, pm-utils does not support all
quirks that are used there.
Comment 8 Michal Jaegermann 2008-01-08 13:29:56 EST
> Btw. suspend and hibernate seems to work for the eeepc sometimes
> according to http://code.google.com/p/eee-ubuntu-support/

I am pretty sure that I could have both working with F8 but if I would
have that installed on a "main disk" and not on an extra SD card which
is accessed via USB.  Not likely with pm-utils, though. See also
http://wiki.eeeuser.com/ubuntu#suspend_resume
although I am not entirely convinced if they are not tad too optimistic
there.  Maybe.

I do not have a hardware right now but maybe even in this configuration
I was using there is some way around a need to wake up USB, in order
to make an installation accessible, without trying to access filesystems
first.  That was the last stumbling block.

> but sadly, pm-utils does not support all quirks that are used there.

In my experiments pm-utils were missing hooks which, basically, would
allow me to run custom scripts instead of regular ones.  One of reasons
why I tried to find a configuration which would allow me to just turn
that off.
Comment 9 Till Maas 2008-01-08 13:40:42 EST
(In reply to comment #8)

> > but sadly, pm-utils does not support all quirks that are used there.
> 
> In my experiments pm-utils were missing hooks which, basically, would
> allow me to run custom scripts instead of regular ones.  One of reasons
> why I tried to find a configuration which would allow me to just turn
> that off.

It is not yet documented, you run "overwrite" every script from
/usr/lib/pm-utils/sleep.d/
with a identically named script in
/etc/pm/sleep.d
They scripts get as first argument suspend, hibernate, resume or thaw, depending
on what is happening.
Comment 10 Richard Hughes 2008-04-08 03:55:59 EDT
Is this now fixed upstream? http://pm-utils.freedesktop.org/wiki/
Comment 11 Michal Jaegermann 2008-04-08 13:40:09 EDT
I am looking at those upstream sources and it seems to me that they are
even more broken for this issue than before.  It appears that indeed by
unsetting HIBERNATE_MODE, and which should be possible in some configuration
file, you can prevent attempts to hibernate _if_ pm/moduled.d/kernel is in
use.  Otherwise you are SOL.  I cannot find any provisions which would do
similar things for suspend.

This is a wrong level anyway and such switch should likely be checked
in 'pm-action'.  $INHIBIT is not an answer as you in 'pm-action' you
have 'rm -f "${INHIBIT}"'.

BTW - a test 'grep -q "${HIBERNATE_MODE}" /sys/power/disk' from
pm/module.d/kernel is broken too.  For example "shut" will match
even if such mode is not valid (also "test" when only "testproc" is
available).  That should be 'grep -qw ...'.

I did not attempt a review with a fine-tooth-comb.
Comment 12 Till Maas 2008-04-14 14:24:46 EDT
To use ${INHIBIT} you need to add a hook that creates it upon invokation, afaics
the ${INHIBIT} is intended to give hooks a mean to abort the sleep.
Comment 13 Till Maas 2008-04-14 16:33:54 EDT
(In reply to comment #11)

> BTW - a test 'grep -q "${HIBERNATE_MODE}" /sys/power/disk' from
> pm/module.d/kernel is broken too.  For example "shut" will match
> even if such mode is not valid (also "test" when only "testproc" is
> available).  That should be 'grep -qw ...'.

Thanks, this code is currently only in the upstream repository. I changed this.
Comment 14 Bug Zapper 2008-05-14 00:15:54 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Bug Zapper 2009-06-09 19:19:26 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 16 Bug Zapper 2009-07-14 12:05:55 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 17 Bug Zapper 2009-11-16 02:59:52 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 18 Bug Zapper 2010-11-04 08:03:48 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Bug Zapper 2010-12-05 02:13:52 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.