Bug 904221 - pm-utils scripts do not get executed when resuming a system from sleep
Summary: pm-utils scripts do not get executed when resuming a system from sleep
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 909867 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-25 19:19 UTC by Artur M.
Modified: 2013-09-03 01:26 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-07 12:50:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Artur M. 2013-01-25 19:19:54 UTC
Description of problem:
After resume from sleep, neither the /etc/pm/sleep.d nor /lib64/pm-utils/sleep.d scripts get executed. This happens only when suspending/resuming by closing/opening the lid. When suspending the system by selecting 'suspend' from the GNOME menu, pm-utils seems to detect the suspension event correctly as the scripts get executed.

Tested with Lenovo Thinkpad X230.

It seems that with 3.6.10 pm-utils detect the 'suspend' event correctly, but with 3.7.2 and 3.7.4 (testing) they do not. Possibly this could (or even should) be filed as a kernel bug.

Version-Release number of selected component (if applicable):

Steps to Reproduce:
1. close the lid 
2. open the lid
3. check /var/log/pm-suspend.log for messages

Actual results:
No script gets executed, and pm-suspend.log has no new log entries.

Expected results:
/usr/lib64/pm-utils/sleep.d scripts get executed and the execution is logged in pm-suspend.log.

Additional info:
This can also be related to the fact that after resuming, the screen brightness is reset to the maximal value.

Comment 1 Jaroslav Škarvada 2013-01-25 22:28:43 UTC
In f18 suspend is implemented in systemd and it doesn't call pm-utils. For the better flexibility I think it should. Reassigning to systemd.

Comment 2 Artur M. 2013-01-26 22:53:36 UTC
Jaroslav, thanks for the hint. I have fixed that by adding a script to /usr/lib/systemd/system-sleep that calls pm-utils. Now the brightness of the screen gets restored correctly!

I think it would be really good to have systemd call pm-utils, as it supports various quirks and performs various post-sleep operations.

Comment 3 Lennart Poettering 2013-01-29 03:59:42 UTC
Why would we still want pm-suspend in the loop? We asked the X folks and others regarding the quirks situation and they told us that userspace quirks were no longer necessary for anything.

So, why should we leave pm-suspend in there?

Comment 4 Artur M. 2013-01-29 08:01:40 UTC
(In reply to comment #3)
> So, why should we leave pm-suspend in there?

After resuming (on TP X230) the screen brightness is reset to the maximal value. When I call pm-utils while resuming the brightness gets back to its previous setting. However, I think that pm-utils wasn't really needed for that with kernel 3.6.10.

Comment 5 Lennart Poettering 2013-01-30 01:31:15 UTC
Artur, that really sounds like something to fix in the kernel, for example in the thinkpad kernel driver. Userspace work-arounds should not be required for that.

Comment 6 Jaroslav Škarvada 2013-02-04 09:23:10 UTC
(In reply to comment #3)
> Why would we still want pm-suspend in the loop? We asked the X folks and
> others regarding the quirks situation and they told us that userspace quirks
> were no longer necessary for anything.
> 
> So, why should we leave pm-suspend in there?

It is for added flexibility, the user can:

a) unload modules
b) run it's own scripts on suspend/resume

For a) it is good for temporal (custom) workarounds for various problems, because it can take very long the kernel fix is available and it's better to be able to create custom workaround than to have broken suspend/resume on the affected machine.

For b), various users needs to call various scripts on suspend/resume (like re-mounting shares).

a) can be resolved by b). Is there any possibility now how to run custom scripts?

Comment 7 Artur M. 2013-02-04 15:08:29 UTC
(In reply to comment #6)
> b). Is there any possibility now how to run custom
> scripts?

It seems there is. The scripts could be put in:
 /usr/lib/systemd/system-sleep

Comment 8 Lennart Poettering 2013-02-04 17:56:19 UTC
(In reply to comment #6)
> (In reply to comment #3)
> > Why would we still want pm-suspend in the loop? We asked the X folks and
> > others regarding the quirks situation and they told us that userspace quirks
> > were no longer necessary for anything.
> > 
> > So, why should we leave pm-suspend in there?
> 
> It is for added flexibility, the user can:
> 
> a) unload modules

Unloading modules is a developer/debugging tool, it never should be part of any codepaths we ship.

> b) run it's own scripts on suspend/resume

This is available in /usr/lib/systemd/system-sleep/

See "systemctl help systemd-suspend.service" for more information.

Comment 9 Jaroslav Škarvada 2013-02-11 13:23:45 UTC
*** Bug 909867 has been marked as a duplicate of this bug. ***

Comment 10 Miroslav Lichvar 2013-02-11 17:03:32 UTC
/usr/lib/systemd/system-sleep/ is not a very good place for user scripts, is there an equivalent in /etc?

Also, is there a document/blog post explaining why it was necessary to duplicate this functionality in systemd and break pm-utils? I couldn't find any. I think at least it deserved to be mentioned in the F18 release notes.

Comment 11 Lennart Poettering 2013-03-07 12:50:16 UTC
(In reply to comment #10)
> /usr/lib/systemd/system-sleep/ is not a very good place for user scripts, is
> there an equivalent in /etc?

Code doesn't really belong in /etc. That's for configuration.

> Also, is there a document/blog post explaining why it was necessary to
> duplicate this functionality in systemd and break pm-utils? I couldn't find
> any. I think at least it deserved to be mentioned in the F18 release notes.

It's hardly "duplicated". We just cleaned up things a bit, and dropped one step.


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