You are not logged in.

#1 2017-12-10 09:59:10

xor1
Member
Registered: 2016-04-12
Posts: 12

erroneous lid open resume behaviour

When I close the lid, and reopen of my Thinkpad T440S, it resumes, however it immediately resets the Desktop Environment - it seems.
This behaviour is since it ran out of battery and completely switched off. Before that, it would simply suspend and wake up.
The DE is cinnamon, the OS is arch.

notes:
when suspending manually, and resuming, all works fine.
Even when suspending manually and closing the lid, and opening again, all works fine.
Only when closing the lid and opening again, resuming goes wrong.

Suspicion: Maybe it hibernated to disk when running out of battery, and it tries to restore this when closing and opening the lid or something like this. I never had hibernation working properly on this machine.

I believe that the lid switch behaviour is managed by systemd, and in the past I set up lid switch behaviour properly by editing systemd/logind.conf and removing other power management systems.

How can I investigate this matter further?


/etc/systemd/logind.conf:

[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
#InhibitDelayMaxSec=5
HandlePowerKey=suspend
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
HandleLidSwitch=suspend
#HandleLidSwitchDocked=ignore
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#HoldoffTimeoutSec=30s
#IdleAction=ignore
#IdleActionSec=30min
#RuntimeDirectorySize=10%
#RemoveIPC=yes
#InhibitorsMax=8192
#SessionsMax=8192
#UserTasksMax=33%

/etc/UPower/UPower.conf:

[UPower]

# Enable the Watts Up Pro device.
#
# The Watts Up Pro contains a generic FTDI USB device without a specific
# vendor and product ID. When we probe for WUP devices, we can cause
# the user to get a perplexing "Device or resource busy" error when
# attempting to use their non-WUP device.
#
# The generic FTDI device is known to also be used on:
#
# - Sparkfun FT232 breakout board
# - Parallax Propeller
#
# default=false
EnableWattsUpPro=false

# Don't poll the kernel for battery level changes.
#
# Some hardware will send us battery level changes through
# events, rather than us having to poll for it. This option
# allows disabling polling for hardware that sends out events.
#
# default=false
NoPollBatteries=false

# Do we ignore the lid state
#
# Some laptops are broken. The lid state is either inverted, or stuck
# on or off. We can't do much to fix these problems, but this is a way
# for users to make the laptop panel vanish, a state that might be used
# by a couple of user-space daemons. On Linux systems, see also
# logind.conf(5).
#
# default=false
IgnoreLid=false

# Policy for warnings and action based on battery levels
#
# Whether battery percentage based policy should be used. The default
# is to use the time left, change to true to use the percentage, which
# should work around broken firmwares. It is also more reliable than
# the time left (frantically saving all your files is going to use more
# battery than letting it rest for example).
# default=true
UsePercentageForPolicy=true

# When UsePercentageForPolicy is true, the levels at which UPower will
# consider the battery low, critical, or take action for the critical
# battery level.
#
# This will also be used for batteries which don't have time information
# such as that of peripherals.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# PercentageLow=10
# PercentageCritical=3
# PercentageAction=2
PercentageLow=10
PercentageCritical=3
PercentageAction=2

# When UsePercentageForPolicy is false, the time remaining at which UPower
# will consider the battery low, critical, or take action for the critical
# battery level.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# TimeLow=1200
# TimeCritical=300
# TimeAction=120
TimeLow=1200
TimeCritical=300
TimeAction=120

# The action to take when "TimeAction" or "PercentageAction" above has been
# reached for the batteries (UPS or laptop batteries) supplying the computer
#
# Possible values are:
# PowerOff
# Hibernate
# HybridSleep
#
# If HybridSleep isn't available, Hibernate will be used
# If Hibernate isn't available, PowerOff will be used
CriticalPowerAction=HybridSleep

Offline

#2 2017-12-10 20:05:50

GenkiSky
Member
From: This account is henceforth dis
Registered: 2017-04-04
Posts: 82

Re: erroneous lid open resume behaviour

How do you mean by "resets the Desktop Environment - it seems" ? As in it logs you out, the DE crashes, computer reboots, ... ? Also, if this issue started appearing after a battery die, is it possible the different is just you are now in an upgraded kernel? How often do you reboot otherwise? Also, I'm confused about your printing your UPower config, when my reading is you said you don't use other power management systems besides systemd's logind.conf.

Offline

#3 2017-12-10 21:29:12

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Hi Thanks GenkiSky, I will try to clarify.
I am not entirely sure what happens after lid opening. But it seems that although the laptop is not rebooting, the DE does restart. It goes back to the greeter I get after booting up - which is different from the one after resuming from suspend - and all applications are closed. Like when restarting the DE command line.

Also, the laptop goes into suspend it seems, because the power light breathes on and off as normally when in suspend.

I am not sure what the UPower system is, I hassled in the past to get the right power managers installed and others uninstalled from my system, and do not recall having seen this one before. I noticed, while searching for solutions, that people were mentioning this file and I thought it might be of importance.

I find this power management stuff extremely frustrating tbh and can never seem to figure out what system or subsystem is taking care of my power management, so I really hope someone can give me some pointers on where to investigate. I thought I had finally figured it out and for a while it was more or less acceptable, except no hibernate nor suspend when battery low. It would just switch off and kill all my work.

Any help is greatly appreciated!

Offline

#4 2017-12-11 08:40:55

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Addendum: I actually see first that it resumes from suspend, like normal, showing me the suspend-greeter, but then it goes to the boot-time greeter.

Offline

#5 2017-12-13 13:59:02

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Hi,
I have some updates about this matter. I hope someone will be able to help me still!
here is the output of journalctl -b -u systemd-suspend:

-- Logs begin at Mon 2016-03-07 00:06:52 CET, end at Wed 2017-12-13 14:52:20 CET. --
Dec 13 03:08:50 sputnik systemd[1]: Starting Suspend...
Dec 13 03:08:50 sputnik systemd-sleep[2695]: Suspending system...
Dec 13 10:08:02 sputnik systemd-sleep[2695]: System resumed.
Dec 13 10:08:02 sputnik systemd[1]: Started Suspend.
Dec 13 13:36:59 sputnik systemd[1]: Starting Suspend...
Dec 13 13:36:59 sputnik systemd-sleep[11167]: Suspending system...
Dec 13 14:51:56 sputnik systemd-sleep[11167]: System resumed.
Dec 13 14:51:56 sputnik systemd[1]: Started Suspend.

you see that systemd[1] starts suspend after systemd-sleep has resumed the system.

My /etc/systemd/logind.conf now has the following statement for handlelidswitch:

HandleLidSwitch=ignore

Why-oh-why is systemd still suspending my system when i close the lid, and why does it sort of resuspend it after i open the laptop again?

Last edited by xor1 (2017-12-13 14:00:17)

Offline

#6 2017-12-13 15:41:49

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,425

Re: erroneous lid open resume behaviour

Systemd will always be the one suspending your system, even if the suspend is triggered by a different entity (Or rather logind != systemd). What have you set up in your DE's power management settings?

Which additional potential power management tools have you installed? you make some vague claims as to other "power management solutions", ideally if you use a full featured DE like cinammon they will ship with a power management solution for lid switches and the like and you should be using that. If you want help figuring this out, post your pacman.log

Since you already posted it, what happens if you set the IgnoreLid option to true in your Upower conf?

A quick googler shows that there should be gsettings you can set to make the cinammon power manager use/respect logind, what happens if you switch around with the implementations here? https://www.linuxmint.com/rel_rafaela_c … atsnew.php

Something you also should do if none of this helped so far, is rule out a kernel regression by using e.g. linux-lts as opposed to linux.

Last edited by V1del (2017-12-13 16:09:38)

Offline

#7 2017-12-13 16:29:56

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Hi V1del, thank you very much for these suggestions!

I tried now the following: I set the Upower conf IgnoreLid to true, but I do not know how to see if that service was even running. From systemctl I could not find out it was running or how to restart it.
I selected "do nothing" in the cinnamon lid switch settings, and after doing these things the following happened:
after closing the lid, the laptop remained turned on; after opening again, the DE was logged out and the screen remained black. Switching to terminal console (Ctrl-Alt-F6) and back to X console (Ctrl-Alt-F7) made it reappear again with greeter.
After rebooting, closing the lid does not do anything anymore.
After changing systemd-logind setting back to suspend, still nothing.
logind does seem to recognize the opening and closing of the lid, judging from the journalctl

Most notable maybe is that the option for lid closing behaviour setting disappeared from the cinnamon power manager!

I will investigate further, looking first at the linux mint page suggestion. I will report back findings, if it is still needed i can upload the pacman log.

Offline

#8 2017-12-13 17:06:03

V1del
Forum Moderator
Registered: 2012-10-16
Posts: 21,425

Re: erroneous lid open resume behaviour

Upower is what most of the power managers in DE environments use to set power settings, it is an abstraction library, afaik not necessarily service . And as evident, by setting it to IgnoreLid cinammon followed suit and removed the option. What would be interesting now if just that part is handled by logind now, and if changing the setting (iirc you can force a reparse of the configuration files via

systemctl reload systemd-logind

) would now result in correct behaviour.

However overall, I'd think that if changing the gsetting to make the cinnamon session daemon use logind works as I'd expect it to that might be the most favorable solution, granted that it does work correctly.

Last edited by V1del (2017-12-13 17:10:18)

Offline

#9 2017-12-22 15:42:15

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Hi V1Del,

Thanks for the explanation. Indeed when I removed hte ignorelid=true from UPower configuration, the option returned in Cinnamon power manager.
Also the weird behaviour returned: computer suspends when lid closes, and when resume, it first shows the normal lock screen and then falls back to start up greeter - having closed my session.

I tried reloading systemd-logind, but this did not work:

Failed to reload systemd-logind.service: Job type reload is not applicable for unit systemd-logind.service.
See system logs and 'systemctl status systemd-logind.service' for details.

I restarted it using restart.
It does not seem to work though, despite having the cinnamon setting with gsettings as you pointed out. The systemd-logind service is running but does not resond to lid switch.
For the past week I have been suspending my computer from command line prior to closing it, but this works poorly - besides it being cumbersome; sometimes the computer immediately resumes again after suspending, with the lid still closed. Makes me almost want to wipe the whole thing and install Ubuntu again.

Offline

#10 2018-01-21 20:38:35

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Why does the computer now resume, after I manually suspend and close the lid? How can I find out which mechanism is doing this?

Offline

#11 2018-01-26 14:54:51

xor1
Member
Registered: 2016-04-12
Posts: 12

Re: erroneous lid open resume behaviour

Awesome. I fixed it by switching to (yet) another window manager. In awesome-wm, systemd-logind behaves as expected. It is also significantly faster.

Seems after countless hours of digging through docs, scripts, source code and trying configurations, I could not fix it in cinnamon. The final situation was that: either I would let UPower take care of the lid switch, and this would let the session log out on resume. Or I would let systemd-logind take care of it, but it would not do it. In fact it would do the opposite, when I manually suspended, it would resume when I close the lid.

Thanks for your input guys.

Offline

Board footer

Powered by FluxBB