[Solved] Suspend problem after updating 'systemd'

archie0 · 2012-09-28 06:57:38

So. After the yesterday's systemd update (192-1), I'm having a problem with 'suspend'.

When I close my laptop's lid, it suspends, as expected. After I open it up, it resumes from suspend and then immediately suspends again.

Anybody else experiencing this issue?

systemd - 192-1
systemd-sysvcompat - 192-1

Last edited by archie0 (2012-09-29 04:57:53)

bernarcher · 2012-09-28 07:03:55

Similar case solved in https://bbs.archlinux.org/viewtopic.php?id=149705
You will likely have to edit /etc/systemd/logind.conf

archie0 · 2012-09-28 07:33:12

I've messed a bit with "LidSwitchIgnoreInhibited" but I couldn't get it going.

Edit. Solved the problem. I don't know who wrote the manual, but it's a bit tricky to understand at first.

It seems like it was the same problem, my power button event was messed up as well. I've un-commented the 'Handle-*' options and set the parameter to 'ignore'. Everything is fine but it seems like logind is buggy, isn't it? If I use it over my DEs Power Settings the suspend function doesn't work as expected.

Last edited by archie0 (2012-09-28 07:53:45)

Scimmia · 2012-09-28 15:19:39

I'm guessing the problem is that both are trying so suspend when you close the lid. One of them is successful, the system suspends, then when it's woken up the other issues it's suspend command.

The inhibit options only work if the DE power manager issues the inhibit commands, it's probably too new for any of them to support that yet.

Last edited by Scimmia (2012-09-28 17:27:22)

teateawhy · 2012-09-29 00:29:04

Now that systemd provides these features there are 3 programs competing to do the same. The powermanager of the DE like gnome/Kde , systemd , and acpid.
Choose one of them and disable the others completely or you will end up with strange behaviour like here.

archie0 · 2012-09-29 04:57:39

It makes sense. I'll try disabling my DEs power actions and try only with 'loginctl'.

Thanks guys.

ijanos · 2012-09-29 09:24:22

The same double-suspend thing happaned to me too. I disabled acpid and it only suspends once but now the scripts in /etc/pm/sleep.d doesn't run after resume. Are there any existing solution for this our should I start hacking together something?

dejavu · 2012-09-29 09:59:09

ijanos wrote:

The same double-suspend thing happaned to me too. I disabled acpid and it only suspends once but now the scripts in /etc/pm/sleep.d doesn't run after resume. Are there any existing solution for this our should I start hacking together something?

https://wiki.archlinux.org/index.php/Systemd#Example

ijanos · 2012-09-29 10:07:14

dejavu wrote:

ijanos wrote:
The same double-suspend thing happaned to me too. I disabled acpid and it only suspends once but now the scripts in /etc/pm/sleep.d doesn't run after resume. Are there any existing solution for this our should I start hacking together something?
https://wiki.archlinux.org/index.php/Systemd#Example

I know. This is why I asked. So I should wrote my own, there is no transition package in aur that will do it for me

dejavu · 2012-09-29 10:10:55

ijanos wrote:

dejavu wrote:
ijanos wrote:
The same double-suspend thing happaned to me too. I disabled acpid and it only suspends once but now the scripts in /etc/pm/sleep.d doesn't run after resume. Are there any existing solution for this our should I start hacking together something?
https://wiki.archlinux.org/index.php/Systemd#Example
I know. This is why I asked. So I should wrote my own, there is no transition package in aur that will do it for me

AFAIK no. But you only have to insert your 'scripts' in one of the two sections (pre and post).

ijanos · 2012-09-29 10:15:20

dejavu wrote:

ijanos wrote:
dejavu wrote:
https://wiki.archlinux.org/index.php/Systemd#Example
I know. This is why I asked. So I should wrote my own, there is no transition package in aur that will do it for me
AFAIK no. But you only have to insert your 'scripts' in one of the two sections (pre and post).

Yeah but I want them to run parallel, so I should write a new one for each.

tomk · 2012-09-29 10:38:32

I prefer this method:

systemd wiki page wrote:

Note that you can also use sleep.target, suspend.target or hibernate.target to hook units into the sleep state logic instead of using scripts.

IOW, write units for whatever you currently have scripts for e.g. I have one that calls i3lock before suspend/hibernate.

ijanos · 2012-09-29 11:46:51

tomk wrote:

I prefer this method:
systemd wiki page wrote:
Note that you can also use sleep.target, suspend.target or hibernate.target to hook units into the sleep state logic instead of using scripts.
IOW, write units for whatever you currently have scripts for e.g. I have one that calls i3lock before suspend/hibernate.

Well, "porting" the 3 scripts took like a minute of my time. What are the advantages of using units?

tomk · 2012-09-29 12:09:36

More logical and consistent IMO - if you're using systemd, use systemd for as much as you can.

OTOH, whatever works for you.

Scimmia · 2012-09-29 18:19:25

Easy solution would be to disable the logind power controls and just use acpid.

ijanos · 2012-09-29 19:09:42

Scimmia wrote:

Easy solution would be to disable the logind power controls and just use acpid.

the systemd suspend/resume just seems faster

ChALkeR · 2012-09-30 10:56:37

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.

Last edited by ChALkeR (2012-09-30 10:56:58)

Scimmia · 2012-09-30 11:34:15

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.

Actually the new version won't fix the issue in this post at all. You'll still need to disable the LidSwitchIgnoreInhibited, which is on by default, if you want to control the lid switch behavior inside your DE's power manager. If you don't, you'll still get double suspends. And remember, some of us don't want the laptop to suspend when closing the lid.

Last edited by Scimmia (2012-09-30 11:39:05)

ChALkeR · 2012-09-30 12:38:23

Scimmia wrote:

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.
Actually the new version won't fix the issue in this post at all. You'll still need to disable the LidSwitchIgnoreInhibited, which is on by default, if you want to control the lid switch behavior inside your DE's power manager. If you don't, you'll still get double suspends. And remember, some of us don't want the laptop to suspend when closing the lid.

Seems true about LidSwitchIgnoreInhibited, looks like i was wrong, sorry.
Then, such behaviour from systemd side is strange, it doesn't look like a sane default to me.
Poettering said in irc that inhibiting "handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch" would work fine, but it looks like it wouldn't with the default logind.conf.

Manual says:

man logind.conf wrote:

PowerKeyIgnoreInhibited=, SuspendKeyIgnoreInhibited= and HibernateKeyIgnoreInhibited= defaults to off, LidSwitchIgnoreInhibited= defaults to yes. This means that the lid switch does not respect suspend blockers by default, but the power and sleep keys do.

Edit: no, Scimmia, you are wrong.

I was told in conversaion at the #systemd channel that the LidSwitchIgnoreInhibited parameter is not related to inhibiting the «lid close» event, but, instead, it tells systemd to ignore suspend (not key events) inhibits when the lid close event is not inhibited and handeled by systemd itself.

Last edited by ChALkeR (2012-09-30 13:20:42)

bwat47 · 2012-09-30 20:41:31

ijanos wrote:

tomk wrote:
I prefer this method:
systemd wiki page wrote:
Note that you can also use sleep.target, suspend.target or hibernate.target to hook units into the sleep state logic instead of using scripts.
IOW, write units for whatever you currently have scripts for e.g. I have one that calls i3lock before suspend/hibernate.
Well, "porting" the 3 scripts took like a minute of my time. What are the advantages of using units?

Yeah, as an example, I had a pm-utils script I had always used to workaround a suspend bug (I actually don't even need the script anymore for suspend to work with systemd's suspend, but I do still need it for hibernate to work correctly), and I literally just had to change 2 lines for it to work as a systemd-sleep hook:

system-sleep: http://pastie.org/4792462
Original pm-utils: http://pastie.org/4792491

Last edited by bwat47 (2012-09-30 20:44:07)

mbrennr · 2012-10-02 05:42:50

Same problem. Immediate suspend only on lid close, using gnome, systemd-logind. I think gnome catches the lid close, too. How Do I see which program does the extra suspend?

WonderWoofy · 2012-10-02 05:47:36

Seriously?!?! Did you read the thread?

Scimmia · 2012-10-02 06:26:14

ChALkeR wrote:

I was told in conversaion at the #systemd channel that the LidSwitchIgnoreInhibited parameter is not related to inhibiting the «lid close» event, but, instead, it tells systemd to ignore suspend (not key events) inhibits when the lid close event is not inhibited and handeled by systemd itself.

Told by who? I think you're misinterpreting something (or I'm completely missing what you said). The man page and even the name of the options itself are pretty clear. "The lid switch does not respect suspend blockers by default" is hard to misunderstand.

ChALkeR · 2012-10-02 20:12:30

Scimmia wrote:

"The lid switch does not respect suspend blockers by default" is hard to misunderstand.

Yet we both did misunderstand it.
Here are two examples:

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.

Example B
0) LidSwitchIgnoreInhibited is enabled in logind.conf, HandleLidSwitch=suspend (the default values).
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 "sleep". For example, some torrent client.
3) The user closes the lid.
4) systemd does suspend the notebook without any confirmation dialogs, despite the fact that "sleep" is inhibited. This is where the LidSwitchIgnoreInhibited flag is used.
5) The notebook is suspended only once by systemd.

mbrennr · 2012-10-02 22:11:51

For testing:
HandleLidSwitch=suspend
LidSwitchIgnoreInhibited=no

Reboot. Log into GNOME. Then test: Close lid, power back on, it works as expected.
Then cycle AC, pull and reinsert power cord, making laptop battery powered.
Test agein: Close lid, open lid push power button, and immediate suspend on resume is back.
There's a bug somewhere. (Systemd takes over from GNOME, ignores inhibitor anyway.)

Workaround:

Set
HandleLidSwitch=ignore
LidSwitchIgnoreInhibited=no

Let GNOME handle the business...

Arch Linux

#1 2012-09-28 06:57:38

[Solved] Suspend problem after updating 'systemd'

#2 2012-09-28 07:03:55

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

#3 2012-09-28 07:33:12

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

#4 2012-09-28 15:19:39

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

#5 2012-09-29 00:29:04

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

#6 2012-09-29 04:57:39

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

#7 2012-09-29 09:24:22

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

#8 2012-09-29 09:59:09

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

#9 2012-09-29 10:07:14

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

#10 2012-09-29 10:10:55

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

#11 2012-09-29 10:15:20

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

#12 2012-09-29 10:38:32

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

#13 2012-09-29 11:46:51

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

#14 2012-09-29 12:09:36

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

#15 2012-09-29 18:19:25

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

#16 2012-09-29 19:09:42

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

#17 2012-09-30 10:56:37

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

#18 2012-09-30 11:34:15

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

#19 2012-09-30 12:38:23

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

#20 2012-09-30 20:41:31

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

#21 2012-10-02 05:42:50

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

#22 2012-10-02 05:47:36

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

#23 2012-10-02 06:26:14

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

#24 2012-10-02 20:12:30

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

#25 2012-10-02 22:11:51

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

Board footer