Bug 12489

Summary: No way to avoid suspending after a shutdown is requested
Product: Mageia Reporter: Jérôme Borme <jerome>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED OLD QA Contact:
Severity: normal    
Priority: Normal CC: balcaen.john, lmenut, mageia, mageia, mageia, olivier, tmb
Version: 4   
Target Milestone: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Source RPM: CVE:
Status comment:

Description Jérôme Borme 2014-01-31 10:56:29 CET
In KDE, I select to turn off the system. Immediately after that I close the laptop lid. This is the order of operation that makes sense to the user.

Because the lid is closed, the system goes into suspend before the end of the shutdown. When I turn on the laptop, battery is lower (because suspend uses battery), and it only turns on 10 second to finish to the shutdown procedure.

I think the shutdown procedure should disable suspend/hibernate acpi requests.

Reproducible: 

Steps to Reproduce:
Sander Lepik 2014-01-31 11:10:04 CET

CC: (none) => balcaen.john, lmenut, mageia, mageia, mageia

Comment 1 Colin Guthrie 2014-01-31 14:07:32 CET
As I'm at a systemd hackfest right now I discussed this issue with folk here.

It's trickier issue than you might think as there are a lot of factors involved. Some people are requesting that a timestamp from each generating event is recorded and sent down the stack such that we can react to the one that came in first, but the problem is if suspend technically is requested first, but the shutdown even is triggered at almost exactly the same time but somehow makes it to the systemd faster (due to processor scheduling etc). When the suspend event reaches the lower levels, shutdown might already be underway and "reversing" that process is likely impossible to honour instead the suspend event.

Now the above race is probably not affecting this particular issue, but the core principle is the same sadly.

But I agree in principle that this would be nice to solve, so will continue to look into it.
Comment 2 Olivier FAURAX 2014-10-23 10:06:32 CEST
Is there any progress on this issue?
Is this still valid in cauldron and/or recent systemd?
Is it OK to set the RPM package of this bug to systemd?

CC: (none) => olivier

Comment 3 Thomas Backlund 2014-10-23 11:15:09 CEST
Then you also have hw issue where the hw/bios/uefi overrides anything done is software, so the fix is not "obvious"

CC: (none) => tmb

Comment 4 Colin Guthrie 2014-10-23 12:03:59 CEST
Not sure if there is a solution yet actually. Forgot to chase the issue up at the systemd hackfest I was at last week too :(

Will ping a few people and ask if things have progressed yet.
Comment 5 Samuel Verschelde 2015-09-21 13:19:26 CEST
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer 
maintained, which means that it will not receive any further security or bug 
fix updates.

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 
Mageia version.

Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't 
able to fix it before Mageia 4's end of life. If you are able to reproduce it 
against a later version of Mageia, you are encouraged to click on "Version" and 
change it against that version of Mageia. If it's valid in several versions, 
select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.

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 Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].

[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/
Comment 6 Marja Van Waes 2015-10-27 06:56:51 CET
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates.

This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version)

If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 
1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED"
2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release.
Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO.
3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page:
https://wiki.mageia.org/en/How_to_report_a_bug_properly

If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). 


If you would like to help fixing bugs in the future, don't hesitate to join the
packager team via our mentoring program [1] or join the teams that fit you 
most [2].
[1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
[2] http://www.mageia.org/contribute/

Status: NEW => RESOLVED
Resolution: (none) => OLD