Bug 1118663 - Suspend to RAM does not work as non-root
Summary: Suspend to RAM does not work as non-root
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kde-workspace
Version: 20
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Ngo Than
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-11 08:45 UTC by Attila
Modified: 2015-06-29 21:33 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 21:33:21 UTC


Attachments (Terms of Use)

Description Attila 2014-07-11 08:45:26 UTC
User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0
Build Identifier: 

When I try to execute suspend to RAM as "user", it does not work. The only step that seems to work is that the screensaver is activ but the system does not stop. A try to login again fails, because my password will not be accapted. Therefore I need to reboot.
Interesting is that I can send the system to suspend to RAM when I logged in as root.

Reproducible: Always

Steps to Reproduce:
1. Logon to KDE
2. Open the "K-Menu" and point to "Leave
3. Choose "Sleep"
Actual Results:  
The Screensaver is active and the system is up.

Expected Results:  
The system should switch to "suspend to RAM"

The command "pm-is-supported" gives the output:

SUSPEND is supported
HIBERNATE is supported
SUSPENDHYBRID is supported

The following informations could be important.
I am using KDE 4.12.5 on Fedora 20 (kernel 3.15.4-200.fc20.i686+PAE), the services NIS and NFS are activated and the /home directory is served by NFS. The hardware is a ZBOX-ID92/ZBOX-IQ01

Comment 1 Josh Boyer 2014-07-11 13:11:54 UTC
As far as I know you have to be root to suspend the system.  If KDE doesn't have sufficient permissions to do that, then it sounds like a KDE issue.

Comment 2 Rex Dieter 2014-07-11 13:34:12 UTC
KDE just hands it off to systemd (logind) to the hard work.

Reporter, what does this output?

(all one line)
$ qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend

should return: yes


Then, try this to manually initiate a suspend, does it work?

(all one line)
$ qdbus --system org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend 0

Comment 3 Rex Dieter 2014-07-11 13:42:08 UTC
In particular, run those commands from within a konsole (or other shell) in the kde user environment that cannot suspend.

Comment 4 Attila 2014-07-14 07:02:39 UTC
(In reply to Rex Dieter from comment #2)
> KDE just hands it off to systemd (logind) to the hard work.
> 
> Reporter, what does this output?
> 
> (all one line)
> $ qdbus --system org.freedesktop.login1 /org/freedesktop/login1
> org.freedesktop.login1.Manager.CanSuspend
> 
> should return: yes


That's correct. It returns "yes"


> 
> 
> Then, try this to manually initiate a suspend, does it work?
> 
> (all one line)
> $ qdbus --system org.freedesktop.login1 /org/freedesktop/login1
> org.freedesktop.login1.Manager.Suspend 0


This one does not work. No screensaver will be activated. No respond from desktop. I need to do a hard reset.

Comment 5 Rex Dieter 2014-07-14 11:55:17 UTC
OK, it's not a kde problem then.

I suspect you won't be able to suspend reliably in your environment anyway.  NFS is not stateless, so suspending when a user with NFS home is logged-in, will be problematic, at best.

My suspicions are that suspending starts, network gets disconnected, then kde session try to lock/screensave but hangs because $HOME has gone away.

Comment 6 Attila 2014-07-15 07:30:04 UTC
(In reply to Rex Dieter from comment #5)
> OK, it's not a kde problem then.

You are right, that is what I thought too and why I mentioned in my report NFS and NIS.

> 
> I suspect you won't be able to suspend reliably in your environment anyway. 
> NFS is not stateless, so suspending when a user with NFS home is logged-in,
> will be problematic, at best.
> 
> My suspicions are that suspending starts, network gets disconnected, then
> kde session try to lock/screensave but hangs because $HOME has gone away.

I understand and I am not an expert, but what, if the shutdown sequenz would be changed to disconnect the network as the last step.

By the way, I could collect today some more informations from the console during the shutdow sequenz. Here some of the output that could be important:
- A start job is running for suspend
- A stop job is running for session 1 of user "username"
- A stop job is running for /home

I can provide more information if you need. I would love to see that Linux can turn to "sleep mode" in my environment. That would be to me the "next big thing" on Linux to make it a bit more "green IT".

Comment 7 Fedora End Of Life 2015-05-29 12:20:50 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

Comment 8 Fedora End Of Life 2015-06-29 21:33:21 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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.