Bug 14676

Created attachment 5649 [details]
dmesg entries for period spanning hibernation and restoring.

This is the dmesg entries from the period spanning the hibernation and subsequent restoration of the system. 

I can see no hint here of the problem.

Thanks for the report.

I suppose you rebooted after the last kernel, glibc and such updates?

The triage guide tells us to ask for some more output:
https://wiki.mageia.org/en/Triage_guide#Suspend.2FHibernate_issues

I suppose "service dm stop" should be replaced with "systemctl stop dm.service"

Please also attach the "journalctl -a" (as root) output from the moment you tried to let your system hibernate till the moment it was fully back up again.

(I don't know how to catch long running stop jobs....I sometimes see one when powering off, that times out after 90 seconds and am wondering whether that can happen here before hibernating.)

CC: (none) => marja11
Keywords: (none) => NEEDINFO

Yes, I certainly did reboot many times since the updates. 
Running from syslevel 3 ( so no dm is involved at all) it still takes about 85 sec for it to hibernate. 

Another possible symptom. If I power down or reboot the system, I get a message
" A stop job for User Manager 500 " 
comes up and sits there for about 30 or 40 sec. (or maybe more) 
I have no idea if this sympton is linked to the hibernate or not, but it does seem to be something else that is wrong on shutdown.
Note, that "stop job" occurs even if I reboot immediately after I have started up.
Again, no dm running.
Looking at journalctl, it seems to have been because, although I disabled iptables, shorewall still starts up. If I also do systemctl disable shorewall, I do not seem to get that "a stop job.." message, and shutdown takes only about 10 sec. However this does not alter the LONG hibernate, It still takes about 70 sec to hibernate and the disk flashing is still just a bit faster than once per sec.

Note that MCC seems to contain no option for completely disabling the firewall. 

I will attach the journalctl output as well. I am not sure how to limit the times for the journalctl output but can edit it I guess.

Created attachment 5650 [details]
journalctl -a output for period spanning a pm-hibernate to bringing out of hibernation.

journalctl -a output for period from before running pm-hibernate as root to end of bringing out of hibernation. (run level 3) It took about 75 sec to hibernate this time. 

This is after having done shorewall disabling.  

Again the disk access light would flash a bit faster than once per second.

(In reply to w unruh from comment #3)
> Yes, I certainly did reboot many times since the updates. 
> Running from syslevel 3 ( so no dm is involved at all) it still takes about
> 85 sec for it to hibernate. 
> 
> Another possible symptom. If I power down or reboot the system, I get a
> message
> " A stop job for User Manager 500 " 
> comes up and sits there for about 30 or 40 sec. (or maybe more) 
> I have no idea if this sympton is linked to the hibernate or not, but it
> does seem to be something else that is wrong on shutdown.

I don't know whether it is related, either, but it seems possible that some of the "user session jobs not stopping" corner cases didn't get solved yet, so cc'ing Colin
(see also https://bugs.mageia.org/show_bug.cgi?id=12081#c3 )

> Note, that "stop job" occurs even if I reboot immediately after I have
> started up.
> Again, no dm running.
> Looking at journalctl, it seems to have been because, although I disabled
> iptables, shorewall still starts up. If I also do systemctl disable
> shorewall, I do not seem to get that "a stop job.." message, and shutdown
> takes only about 10 sec. However this does not alter the LONG hibernate, It
> still takes about 70 sec to hibernate and the disk flashing is still just a
> bit faster than once per sec.
>

CC: (none) => mageia

(In reply to w unruh from comment #4)
> Created attachment 5650 [details]

> journalctl -a output for period from before running pm-hibernate as root to
> end of bringing out of hibernation. (run level 3) It took about 75 sec to
> hibernate this time. 
> 
I was wrong to think anything would be visible, it doesn't show the hang (like hangs when powering off aren't shown, either) :-/

This is not the same bug as the poweroff, or reboot bug where the system hangs for 90 sec with a "a stop for User Manager kill" message. That can be made less painful by putting 
TimeoutSec=10
into /usr/lib/systemd/system/user@.service after the KillSignal-.. line
But that makes no difference to hibernation bug. Hibernation still takes about 80 sec to complete. 

It also makes no difference to the title bug-- namely that if root was once loggedinto the console, poweroff throws and error message saying root is still logged on even after root has logged off.

I have found that this seems to definitely be a problem in pm-hibernate. It gives that 2 min of disk activity light flashing once per second. 
If I do 
systemctl hibernate
the system hibernates and shuts off in about 15-20 sec, rather than2 min. 
And the disk activity light is on solid the "whole time" ( after avout the first 8 sec while I guess things are being prepared.)

Source RPM: pm-hibernate => pm-hibernate in pm-utils

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/

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