KDE application menu fails to show Suspend and Hibernate options in Power/Session submenu

When starting from cold boot or restart the applications menu fails to show options for Suspend or Hibernate in the Power/Session submenu. I have 2 users defined, user1 and user2. It doesn’t matter which I chose for my initial login; both fail to have Suspend or Hibernate as choices in Power/Session.

For example, here’s the menu for **user1 **after initial login. Note that Suspend and Hibernate do not appear as choices in Power/Session.
http://i.imgur.com/EEPP7LI.png

The only way I can get the Suspend and Hibernate options to display is to logout from the current user and login to my other user. Usually (but not always) these options will appear for the other user. For example, here is the menu for user2 after logout from user1 and login to user2.
http://i.imgur.com/GTuqLJo.png

If the options appear I logout (having done nothing else) and log back in to the first user (in my example, user1). The Suspend and Hibernate options now magically appear as choices in user1’s menu.
http://i.imgur.com/ZUTEXhR.png

This “solution” is an obvious kludge and I have no idea why it works. I would prefer that these options appear on the menu after the initial login for any user.

Is there a more elegant way to achieve this?

Does anyone know why the kludge works?

Thanks in advance for any insights you can offer.

Those options are only hidden if the user doesn’t have the necessary privileges to use them.

Sounds like a polkit issue to me.
There was a bug that caused exactly something like this, but it has been fixed by an update.
So is your system fully up to date?

Another thing that caused similar problems (in 13.2 at least) is autofs. Are you using that?

I suppose your user session is not listed by “loginctl” in case the options don’t show up, right?

re polkit issue - my system is up to date
re autofs - I am not using autofs - also, I’m running Leap 42.1 (not 13.2)
re loginctl - loginctl shows my user session

Thanks for your reply. Any other suggestions? Should I file a bug report?

This is what I get when I run “loginctl”


user3@ws02-linux:~> sudo loginctl
root's password:
   SESSION        UID USER             SEAT            
         1        484 sddm             seat0           
         2       1000 user3            seat0           
2 sessions listed.

Is this correct or what should be expected?

Ok.

re autofs - I am not using autofs - also, I’m running Leap 42.1 (not 13.2)

I know, but I don’t know whether this issue has been fixed already or not.
It might happen in Leap 42.1 as well. Personally, I could never reproduce it in 13.2 either anyway.

First, you don’t need to run it as root, it works without sudo too.
Then, I’m not sure, but I don’t think “sddm” should be listed to be “logged in” at the same seat.

What output do you get when it is working?

Sorry, I failed to explicitly reply to this earlier. The loginctl results I posted earlier were made when the Suspend/Hibernate options did show on the menu.

I retested and found that my user session does show even when Suspend and Hibernate options are not on the application menu.

Here’s how I tested. (1)reboot; (2)login as user3; (3)check if Suspend/Hibernate options are on the application menu (they are not); (4)run loginctl

Here’s the output from loginctl…


user3@ws02-linux:~> loginctl
   SESSION        UID USER             SEAT            
         1        484 sddm             seat0           
         2       1000 user3            seat0 

2 sessions listed.

So whether the options are shown or absent, I get the same output from loginctl.

I have 13.2 running on another computer and I don’t experience this issue there. Only on the computer running Leap 42.1

OK. Thanks for the tip.

I don’t really understand everything loginctl shows. What is a seat? Why shouldn’t ssdm (Simple Desktop Display Manager) be listed at the same seat?

Not quite sure what “it” means. If you’re asking whether Suspend and Hibernate work correctly the answer is yes - both work flawlessly (that’s on the computer running Leap 42.1)

=========
Some Additional Tests

I don’t know if this helps, but I ran 2 additional test scenarios and here are the results…

Scenario A
test: (1)reboot; (2)log in as user2 (suspend and hibernate options are not on the menu); (3) run loginctl

user2@ws02-linux:~> loginctl 
   SESSION        UID USER             SEAT            
         1        484 sddm             seat0           
         2       1001 user2            seat0           

2 sessions listed.

then … (1)log out from user2; (2)log back in as user2; (3)run loginctl


user2@ws02-linux:~> loginctl 
   SESSION        UID USER             SEAT            
         2       1001 user2            seat0           
         4        484 sddm             seat0           
         5       1001 user2            seat0           

3 sessions listed.

Scenario B
After rebooting and logging in as user3 I did this…
test: (1)log out; (2)log in as user2; (3)run loginctl


user2@ws02-linux:~> loginctl 
   SESSION        UID USER             SEAT            
         2       1000 user3            seat0           
        52        484 sddm             seat0           
        53       1001 user2            seat0           

3 sessions listed.

then… (1)log out from user2; (2)log back in as user3; run loginctl


user3@ws02-linux:~> loginctl 
   SESSION        UID USER             SEAT            
         2       1000 user3            seat0           
        53       1001 user2            seat0           
        54        484 sddm             seat0           
        55       1000 user3            seat0           

4 sessions listed.

I’m not sure if I’m interpreting these results correctly but it looks to me like I’m somehow accumulating sessions in these scenarios.

Is this what is supposed to happen? Is there some issue with “registering” the logout? Any explanations you might offer would be sincerely appreciated.

I don’t know if this is relevant but on my computer running openSuse 13.2 I only see a single entry for the current user when I run loginctl. I can log out and log back in as the same (or a different) user and still only see a single entry in loginctl no matter how many times I repeat this process.

Thanks for your help so far. Hope to hear back from you.

Well, a “seat” is basically one particular (physical) workspace, i.e. a keyboard and display.
You can have more than one session running (for different users) on one seat, and can switch between them. That’s what the “Switch Session” option in the menu does.

No idea why sddm is listed there at all, kdm e.g. doesn’t show up.
But that’s probably because sddm’s greeter runs on the same seat (as user sddm) before you login.

Not quite sure what “it” means. If you’re asking whether Suspend and Hibernate work correctly the answer is yes - both work flawlessly (that’s on the computer running Leap 42.1)

No, I was asking what output you get when the Suspend and Hibernate options are shown. IOW, I wanted to know whether there is a difference between the output in both cases, the options shown and the options not shown.

I’m not sure if I’m interpreting these results correctly but it looks to me like I’m somehow accumulating sessions in these scenarios.

Yes, this seems to be a general “problem” in sddm.
I’m not using sddm myself, but I do test it from time to time and noticed the same when using the “Switch User” feature, i.e. all those accumulated sessions will be offered on the “switch user” dialog.
With kdm (the default in a 13.2 KDE installation) this does not happen.

Should not cause an issue though (especially in regards to the Hibernate/Suspend buttons) I think, at least I never noticed one.

You might try with a different displaymanager though, and see whether you can reproduce the problem with Suspend and Hibernate disappearing.
The displaymanager is in fact involved in this… (and Plasma asks the displaymanager whether Suspend or Hibernate is allowed)

xdm is installed by default, but you can also try kdm, gdm, or lightdm e.g. if you want to, you just have to install them first of course.
Switching the displaymanager can be done in /etc/sysconfig/displaymanager, you can also use YaST->System->/etc/sysconfig/ Editor to modify that file (the corresponding variable is DISPLAYMANAGER).

Thank you wolfi323. You’ve been very helpful. I’ll try your suggestions.

FTR, I just switched to sddm again, and actually this is not what I see/saw.
The user switch dialog shows some additional “unused” sessions, but loginctl does not show them, only the logged in users (and sddm “users”).

What you see here might be because some user processes might continue to run after logout and therefore the corresponding session is indeed not completely terminated.
This might be 965922 – KDE session kept alive after logout, for which a fix will be included in the upcoming Plasma 5.5.5 update.

I don’t think this should cause your problem though, especially considering that you see it on first login after boot.
The session not terminating on logout could of course only affect subsequent logins…

One more thing to try would probably be to wait a bit longer with the first login though. The problem might be that some system services take too long to fully start on boot, so not everything might be ready yet when you login. The autofs “problem” I mentioned earlier was such a case (it caused logind to start too late so the user session could not be registered, especially when using Auto-Login, resulting in the user not getting the necessary privileges for certain things including Suspend/Hibernate), but a similar problem might be caused by something else I suppose…

Patience is not my strong suit but I did a cold boot and waited 5+ minutes after the login screen appeared before actually logging in. Alas, no joy. Same issue I described in my initial post.

I am going to install kdm window manager and try again.

I see where to make the required change in the /etc/sysconfig/displaymanager file (from “sddm” to “kdm”).


## Path:        Desktop/Display manager
## Description: settings to generate a proper displaymanager config
## Type:        string(kdm,xdm,gdm,wdm,entrance,console,lightdm,sddm)
## Default:     ""
#
# Here you can set the default Display manager (kdm/xdm/gdm/wdm/entrance/console).
# all changes in this file require a restart of the displaymanager
#
DISPLAYMANAGER="sddm"

You didn’t mention it, but do I also need to make a change in the /etc/sysconfig/windowmanager file from “plasma5” to “kde” (or, possibly, “kde4” ?)???


## Path:        Desktop/Window manager
## Description: 
## Type:        string(gnome,kde4,kde,lxde,xfce,twm,icewm)
## Default:     kde4
## Config:      profiles,kde,susewm
#
# Here you can set the default window manager (kde, fvwm, ...)
# changes here require at least a re-login
DEFAULT_WM="plasma5"

No.
First, there is no “kde” (or “kde4”) session since years. It was renamed to “kde-plasma” at some point in the KDE4 life cycle, which still exists but is actually the same now as “plasma5”. (and “kde” is/was KDE3)
Second, this is only the default anyway, you can choose whatever you want at the login screen.

This doesn’t seem to be sddm-specific. I see it here (Leap/XFCE in a VM) with lightdm, too:

~> loginctl
SESSION UID USER SEAT
2 1000 user seat0
3 485 lightdm seat0
4 1000 user seat0

3 sessions listed.

The display manager is also listed in 13.2 (VM) but I don’t see more than 2 sessions listed there after repeated login/logout.
In 13.1 the display manager is not listed, only the current user.

But I guess this may have nothing to do with the problem.

To see whether suspend/hibernate work irrespective of being displayed in the menu, you can assign keyboard-shortcuts (via the KDE-system-settings) and use those. If they work when the options are not shown, we can rule out permission-/or system-issues.

You may also want to install XFCE as an alternate DE and see if the hibernate/suspend-options are listed there (and work?).

So long!

To all who responded and those looking for a solution…

PRIMARY PROBLEM: lack of Suspend/Hibernate options in Power/Session submenu on initial login
status: UNRESOLVED

SECONDARY PROBLEM: apparent accumulation of login sessions (as shown by the command “loginctl”) when logging out and then logging in to the same or a different user
status: UNRESOLVED (as pointed out by others who responded)

Ultimately I decided that the various “gotcha’s” in Leap were too much for me. I uninstalled Leap and installed 13.2 (which solves both these issues). May revisit Leap in the future if I feel brave.

It might be related to this systemd bug:
https://bugzilla.opensuse.org/show_bug.cgi?id=956033

SECONDARY PROBLEM: apparent accumulation of login sessions (as shown by the command “loginctl”) when logging out and then logging in to the same or a different user
status: UNRESOLVED (as pointed out by others who responded)

As I wrote, this might be caused by processes still running after you logout.
One bug that could cause this should be fixed by today’s Plasma 5.5.5 update for Leap 42.1.
https://bugzilla.opensuse.org/show_bug.cgi?id=965922
(the bug report is still marked as “IN PROGRESS”, but the update does contain the fix)

PS, @Imaginator:
I don’t see the login manager listed here on my 13.2 system.
But it might depend on what login manager you actually use.
Mine is kdm.

Hello there, itś been some time since the last comment in this topic. I hope it is not dead completely.

Iḿ having the same problem with the ¨Hibernate¨ only - the ¨Suspend¨ is present.

I repeated *loginctl *with the following result:

loginctl

SESSION UID USER SEAT
1 1000 User1 seat0
6 484 sddm seat0
7 1000 User1 seat0

3 sessions listed.

But unlike noBananas after logout/login there is no difference - the Hibernate option is missing. The system is Leap 42.1 updated 2 hours ago, on Acer Aspire 5349 laptop.

P.S. Iḿ still looking for solution on this topic: https://forums.opensuse.org/showthread.php/517375-AltGr-not-working-under-Leap-42-1-and-strange-keyboard-behavier?highlight=keyboard+AltGr

As you can notice from my current comment, the keyboard problem persists.

If “Suspend” is present then it shoudn’t be a general problem.

Did you at any point disallow Hibernate maybe?
Please post the file /etc/polkit-default-privs.local.