Bug 427018
| Summary: | allow disabling of pm-hibernate and pm-suspend without running quirks | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||
| Component: | pm-utils | Assignee: | Till Maas <opensource> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 12 | CC: | nathankohagen, opensource, pknirsch | ||||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | FutureFeature | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2010-12-05 07:13:52 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 290540 [details]
a trace from a run 'sh -x /usr/sbin/pm-suspend'
Created attachment 290541 [details]
/var/tmp/suspend.log from the run above
(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? > 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. (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. > 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. 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. > 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. (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. Is this now fixed upstream? http://pm-utils.freedesktop.org/wiki/ 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.
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.
(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. 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 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 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. 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 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 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. |
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