That's right, I masked them by hand following some advice on the internet for
how to make systemd stop suspending, since it was not responding to settings in
login.conf even after restating logind
service.
Regardless of my motivation, it seems buggy that changing these settings
should lead to su
sorry, you can withdraw this bug as I discovered it is a kernel bug, not
systemd.
(I wanted to withdraw it earlier but did not know how to get back to this
report.)
thanks
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to syst
Using systemctl status systemd-logind, I see that lid events are no longer
being detected.
This behavior persists even after restarting the service. This is *not* what
is requested in logind.conf, where HandleLidSwitch=suspend and
HandleLidSwitchDocked=suspend.
--
You received this bug notifi
Public bug reported:
in 20.04.01 LTS (release 20.04), suspend on lid closure works for a
while, then one day stops working, with no error message in syslog. The
event is not even registered. The problem seems to start when the
system has been inactive for long enough so that the screen is blanke
by unmasking sleep.target suspend.target hibernate.target hybrid-
sleep.target, and allowing for suspend on lid closure in login.conf, I
was able to make the problem go away, but why should I be forced to
this?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Public bug reported:
When I close the lid on my laptop, syslog goes crazy with the message
systemd-logind: hibernation is restricted; see man kernel_lockdown.7
repeated ad infinitum, using up all the CPU and GBs of disk space. I am
not even trying to hibernate; everything in /etc/systemd/login.
6 matches
Mail list logo
