To disable this, you have to put "HandleLidSwitch=ignore" in /etc/systemd/logind.conf. Suspending by default, just for closing the laptop lid, is a highly inappropriate action to take, and frankly, so are all of the other options that can be set for HandleLidSwitch. Maybe some people would want to configure such undesirable actions, but the only sane *default* for this is to either blank the screen, or do nothing. I have acpid configured already to blank the screen using vbetool. BTW, also if you disable this craziness and do systemctl restart systemd-logind.service, more craziness ensues. When I tried that, it first made the screen go all fuzzy and wavy when I did blank and unblank the screen using vbetool. Using systemctl suspend, which hibernated the machine, and then unhibernating it did fix the screen craziness. Then I tried systemctl hibernate and the machine suspended. When I booted it back up it really struggled to bring X back, and was in the process of doing that when it spontaneously turned off. Turning it back on again resulted in a normal boot (so basically it crashed and died). Point being, if systemd-logind has lid actions enabled, the only way to safely disable them is rebooting. Reproducible: Steps to Reproduce:
Sorry, but I completely disagree with this suggestion. The only sane action is to suspend and park the disk heads. This has all be thought through and discussed a lot upstream and in various other places and I do not want to rehash the same issues here. The low level stuff must take a safety first approach. If you close your laptop lid it *must* suspend. Closing the lid and running for a bus, finding your laptop was still running and a spinning your disks and losing your data is NOT an option. The user has very little feedback when the lid is closed. If you want to prevent visually or key-based suspend actions, then there are inhibitors in place that allow you to do this and display appropriate UI guidance to the user user explaining that their suspend request has been denied because a DVD is burning or they are rendering a large video or downloading large updates etc. These inhibitors allow for this kind of prevention. You can also take inhibitor locks for the laptop lid at a Desktop Environment level if you like, but it's very much discouraged for the "safety first" reasons given above (although 'delay' inhibitors which give you the chance to react, do stuff, save temporary state files etc, before allowing the suspend/shutdown/reboot or whatever are quite OK) Ultimately the low level tools provide the necessary interfaces and higher level tools often provide ways to override this (e.g. in gnome-tweak-tool, you can change the behaviour of the laptop lid if you really must - not sure about mga3 state of that but it's available in cauldron). Unlike the setting changes the tweaks in the desktop environments happen immediately as they take the inhibitor lock via dbus. systemd-inhibit --list will show you any active inhibitors. If the DE's want to override this behaviour, then they do so via this mechanism and it's generally preferred to do this and give the user a nice UI rather than setting the config file. Anyway, safety first is sensible and it's not something I'd be willing to change as a default. Making it easier for people to make concious decisions is fine, but I'm not going to change something which is based on sound reasoning.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX