[Solved] Suspend problem after updating 'systemd'

ChALkeR · 2012-10-02 22:44:13

mbrennr, have you tried to find the source of the problem?
If there is a bug somewhere, it would be good to report it.

Try «systemd-inhibit --list».

bwat47 · 2012-10-02 23:05:36

I just set them all to ignore and let gnome handle everything.

caskale13c · 2012-10-02 23:58:41

ChALkeR wrote:

btw, kde 4.9.2 (which will come out in a few days) has systemd inhibit support.
Everything will work smooth with the default logind.conf and KDE 4.9.2, even better than it was before (now suspend works in kdm, too).
So, KDE users should just update to 4.9.2 without modifying things in logind.conf.

Having just tried the default logind.conf under KDE 4.9.2. This does not seem to be the case. Unless I modify the logind.conf to ingore handlepowerkey, they system shuts down immediately when the power button is pressed even though I had "Prompt" set in kde power management. I also get the double suspend on lid close.

WonderWoofy · 2012-10-03 00:10:43

caskale13c... how about you go ahead and check what version you are running. Unless you are running [testing], you are not running 4.9.2.

caskale13c · 2012-10-03 00:12:58

I am indeed running testing and a version check does indeed reflect kde 4.9.2.

Scimmia · 2012-10-03 00:31:23

ChALkeR wrote:

Example A
0) LidSwitchIgnoreInhibited is enabled in logind.conf, HandleLidSwitch=suspend (the default values).
1) The user has an active KDE 4.9.2 (or later) session, KDE recieves button events.
2) KDE tells systemd to inhibit "handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch".
3) The user closes the lid.
4) systemd does not suspend the notebook by itself, because "handle-suspend-key" is inhibited. You could think, that this is overriden by LidSwitchIgnoreInhibited, but that is a wrong assumption.
5) The notebook is suspended only once by PowerDevil.

Hmm, you tested this and this is how it works? KDE 4.9.2 is out now, but I haven't had a chance to test it, spent the afternoon replacing the power jack on my notebook.

Edit, so you're saying that the logind just resends the lid switch event as a suspend key event? That doesn't make any sense, what if you have "HandleLidSwitch" set to something different than the suspend key?

Last edited by Scimmia (2012-10-03 00:34:09)

Scimmia · 2012-10-03 01:42:45

Got KDE 4.9.2 installed, I'm getting the same behavior as caskale13c. The inhibited signals don't seem to be working.

Edit, the bug report has been reopened: https://bugs.kde.org/show_bug.cgi?id=307412

Last edited by Scimmia (2012-10-03 02:13:52)

ChALkeR · 2012-10-03 07:30:58

About KDE 4.9.2 — it's a KDE bug. They reviewed one patch and commited another one.
See https://bugs.kde.org/show_bug.cgi?id=307412 for details.

Scimmia wrote:

Hmm, you tested this and this is how it works? KDE 4.9.2 is out now, but I haven't had a chance to test it, spent the afternoon replacing the power jack on my notebook.

Sadly, this doesn't work in KDE 4.9.2, because they lost the file descriptor.

Yes, i did test it with «systemd-inhibit --what=handle-lid-switch:handle-power-key:handle-suspend-key:handle-hibernate-key sleep 9999d» and closing the lid — the suspend happens only once, by KDE, even with LidSwitchIgnoreInhibited=yes.

Scimmia wrote:

Edit, so you're saying that the logind just resends the lid switch event as a suspend key event? That doesn't make any sense, what if you have "HandleLidSwitch" set to something different than the suspend key?

No, it doesn't. What made you think so?

Example C
0) LidSwitchIgnoreInhibited is enabled (the default value) in logind.conf, HandleLidSwitch=poweroff.
1) The user has an active session in a minimalistic DE which does not handle suspend or lid close events by itself. "handle-lid-switch" is not inhibited.
2) The user runs some program, that inhibits "poweroff". For example, some torrent client.
3) The user closes the lid.
4) systemd does poweroff the notebook without any confirmation dialogs, despite the fact that "poweroff" is inhibited. This is where the LidSwitchIgnoreInhibited flag is used.
5) The notebook is turned off by systemd.

Again: LidSwitchIgnoreInhibited just tells systemd to ignore the «action» inhibitor lock when HandleLidSwitch=action and handle-lid-switch is not inhibited.

caskale13c wrote:

[
Having just tried the default logind.conf under KDE 4.9.2. This does not seem to be the case. Unless I modify the logind.conf to ingore handlepowerkey, they system shuts down immediately when the power button is pressed even though I had "Prompt" set in kde power management. I also get the double suspend on lid close.

Sadly, it's broken in 4.9.2.
I reopened the bug.
4.9.3. will be released in the beginning of November.

All:
4.9.2 is broken.
You can put «systemd-inhibit --what=handle-lid-switch:handle-power-key:handle-suspend-key:handle-hibernate-key sleep 9999d» in KDE autostart (not bash autostart!) as a workaround.
Don't forget to remove it (it won't do any harm, just won't be needed) after things get fixed in KDE.
This solution is better than editing logind.conf, it doesn't break suspend in minimalistic desktop enviroments and at the KDM login dialog.
You can test if it works by running «systemd-inhibit --list».

Last edited by ChALkeR (2012-10-03 08:01:10)

Scimmia · 2012-10-03 08:41:22

I've been playing around with systemd-inhibit as well, and it seems you're right. It's a bit convoluted the way it's documented, but by just inhibiting handle-lid-switch with the default logind.conf, the system does nothing when closing the lid. This is probably the best behavior, just not what one would expect looking at the conf file and the man page.

Just so I'm clear, the IgnoreInhibited options are to ignore action locks, not event locks that we've been discussing. As such, they won't really factor into how systemd reacts to a power manager.

ChALkeR · 2012-10-03 09:39:19

Btw, you can vote for the bug: https://bugs.kde.org/show_bug.cgi?id=307412 :-)

ilpianista · 2012-10-05 13:49:49

ChALkeR wrote:

Btw, you can vote for the bug: https://bugs.kde.org/show_bug.cgi?id=307412 :-)

The bug has been fixed, and the patch has been applied to kdebase-workspace 4.9.2-2

Scimmia · 2012-10-05 19:24:35

Just tested it, everything works great with this update. Thank you, ascarpino.

ChALkeR · 2012-10-05 23:31:30

ascarpino, thanks! Everything works now.

Arch Linux

#26 2012-10-02 22:44:13

Re: [Solved] Suspend problem after updating 'systemd'

#27 2012-10-02 23:05:36

Re: [Solved] Suspend problem after updating 'systemd'

#28 2012-10-02 23:58:41

Re: [Solved] Suspend problem after updating 'systemd'

#29 2012-10-03 00:10:43

Re: [Solved] Suspend problem after updating 'systemd'

#30 2012-10-03 00:12:58

Re: [Solved] Suspend problem after updating 'systemd'

#31 2012-10-03 00:31:23

Re: [Solved] Suspend problem after updating 'systemd'

#32 2012-10-03 01:42:45

Re: [Solved] Suspend problem after updating 'systemd'

#33 2012-10-03 07:30:58

Re: [Solved] Suspend problem after updating 'systemd'

#34 2012-10-03 08:41:22

Re: [Solved] Suspend problem after updating 'systemd'

#35 2012-10-03 09:39:19

Re: [Solved] Suspend problem after updating 'systemd'

#36 2012-10-05 13:49:49

Re: [Solved] Suspend problem after updating 'systemd'

#37 2012-10-05 19:24:35

Re: [Solved] Suspend problem after updating 'systemd'

#38 2012-10-05 23:31:30

Re: [Solved] Suspend problem after updating 'systemd'

Board footer