You are not logged in.

#1 2013-05-20 18:21:11

andy4712
Member
Registered: 2013-05-20
Posts: 4

lid closed: who is calling suspend?

Hi there.

I haven't installed acpid nor pm-utils.
My /etc/systemd/logind.conf contains "HandleLidSwitch=ignore".

And yet my Samsung series 9 laptop gets suspended on "lid close".

dmesg shows the same entries whether I invoke "systemctl suspend" or close the lid.

Questions:
  .1 how is the event flow for "lid close" without acpid / pm-utils - who handles the event?
  .2 how can I deactivate the handler or specify my own?

Thanks in advance,

Andy

Last edited by andy4712 (2013-05-20 18:23:04)

Offline

#2 2013-05-20 18:28:59

Raynman
Member
Registered: 2011-10-22
Posts: 1,110

Re: lid closed: who is calling suspend?

Are you using some fancy DE? It could be something like gnome power manager.

dmesg is only for kernel messages, did you check the journal as well?

You can have multiple services handling events. On a clean arch install it would just be systemd(-logind), but it has only a few options. To run whatever you want on lid close, use acpid (and have systemd ignore the lid switch).

Last edited by Raynman (2013-05-20 18:32:55)

Offline

#3 2013-05-20 19:45:46

HenriqueNunnes
Member
Registered: 2013-03-29
Posts: 41

Re: lid closed: who is calling suspend?

@andy4712

In my case I'm using XFCE as DE. I just changed my /etc/systemd/logind.conf

Standard:

#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=ignore

To:

HandlePowerKey=ignore (In my case I need change the Xfce Power Manager the action that I want in this button)
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=ignore

This is my whole file /etc/systemd/logind.conf

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See logind.conf(5) for details

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#Controllers=
#ResetControllers=cpu
#InhibitDelayMaxSec=5
HandlePowerKey=ignore
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=ignore
PowerKeyIgnoreInhibited=yes
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes

Offline

#4 2013-05-20 19:51:12

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: lid closed: who is calling suspend?

systemd-logind handles the suspend if you don't specify otherwise in logind.conf.  After you made those changes to logind.conf, did you restart the service or reboot?  Or are you simply expecting the system to read the config everytime?  Because it doesn't work that way.

Offline

#5 2013-05-20 20:29:17

Scimmia
Bug Wrangler
Registered: 2012-09-01
Posts: 5,120

Re: lid closed: who is calling suspend?

Edit: Removed. Misunderstood a followup.

Last edited by Scimmia (2013-05-20 20:30:07)

Offline

#6 2013-05-21 08:55:44

andy4712
Member
Registered: 2013-05-20
Posts: 4

Re: lid closed: who is calling suspend?

Thanks for your reply, Raynman.

I am using OpenBox.
"journalctl --no-pager | grep suspend" shows only my own invocations of "systemctl suspend" - NOT the ones from closing the lid.

Yes, that's what I want to do - handle ACPI events using acpid, possibly pm-utils.
But I'd like to find out what is going on on my system first - who is handling "lid close" NOW?
You know: IF I stick with Arch, I really want to UNDERSTAND as much as possible, NOT just make it work SOMEHOW.

Last edited by andy4712 (2013-05-21 09:10:00)

Offline

#7 2013-05-21 15:04:33

andy4712
Member
Registered: 2013-05-20
Posts: 4

Re: lid closed: who is calling suspend?

Hi, WonderWoofy.

No, I do not expect the system to read config every time.
And yes, you are right, it WAS systemd-logind.

I just got mislead by the fact that it seems to take a varying time - up to many (20?) seconds - for the handler to get activated after the lid is closed.
Apart from that, I can de/activate systemd-handler by editing /etc/systemd/logind.conf.

Hi, Henrique.

Yes, I have played with the same file. When HandleLidSwitch is commented out, it seems to have the same effect as =suspend.


Thank you all for your replies, guys.

*** PROBLEM SOLVED ***

Offline

#8 2013-05-21 15:55:14

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,412

Re: lid closed: who is calling suspend?

Please mark the thread as [Solved] by editing the first post, which will allow you to also edit the title.

BTW, this issue to delayed suspends is not the first I have heard of this. Others (Samsun machine I think) have reported this problem as well.  You can see if anything simple can be done about it by seeing show long the actual change is shown to have taken place in /sys.  To do this you can either use "udevadm monitor" or acpid also has a tool that will show udev tracked sys changes as well.  So if sends the message through quickly, I imagine that you could actually find a better alternative.  But if it is atually the cahnge in /sys (the udev/acpid mointored mesage) that takes ~20s, then you are just kind of SOL.  That is unless you know C and want to engace in some kernel hacking.

Offline

#9 2013-05-22 15:59:14

HenriqueNunnes
Member
Registered: 2013-03-29
Posts: 41

Re: lid closed: who is calling suspend?

andy4712 wrote:

Hi, Henrique.

Yes, I have played with the same file. When HandleLidSwitch is commented out, it seems to have the same effect as =suspend.

I'm using as DE XFCE, but when I did this configuration in some lines and changed my xfce4-manager-power "actions when lid is closed" -> Do Nothing, for me this worked.

Offline

Board footer

Powered by FluxBB