At Fri, 28 Feb 2014 15:21:18 -0300, Claudio Freire wrote:
On Fri, Feb 28, 2014 at 3:13 PM, Takashi Iwai tiwai@suse.de wrote:
Remember that this can be introduced just by a systemd package update. Then you may have no chance to change the setup before falling into such a situation (or are you changing /etc/logind.conf at each systemd update?).
That's probably the only case you'd care to think about. If it's a new installation, over the network, you expect the sysadmin to do his homework regarding that quite unusual setup.
An update is another matter. Perhaps an update shouldn't change suspending behavior. There's just too many things that can go wrong suspending, not all of them knowable to software. For instance: a desktop that has a PSU unable to supply enough current on suspend state to power the RAM. It happens, such a set up would just crash when it enters the suspension state.
Silently enabling suspension through a patch update is what's wrong here. The update should include a configuration that mimicks previous behavior (or at least some safe behavior).
For new installations, though, you just leave the default. The sysadmin is responsible for checking whether the lid thing works correctly before leaving the system unattendable, especially since unreachable laptops really are a niche thing (perhaps only used for automated QA - the only use case I can think of).
Yes, the bigger question is about the update path. It must not break the working system, and this change would be a high risk.
If the default setup of logind isn't changed (here I mean the real "default" -- the behavior when no config setup is given), the compatible behavior should be kept after the update since /etc/sysgmd.logind.conf is marked as %config(noreplace). OTOH, if the "default" behavior changes secretly, it'll be a problem.
Takashi