This still makes little sense to me. I checked all code paths that call
manager_handle_action(), and they all have a log_info() before it. But
logind doesn't log any of those. Yesterday I only checked evtest on
event0 (the lid switch), I figure we should also watch event1 and event3
(power
This happens around the time when this fires:
Breakpoint 1, manager_handle_action (m=0x55616010,
inhibit_key=INHIBIT_HANDLE_LID_SWITCH, handle=HANDLE_IGNORE,
ignore_inhibited=true, is_edge=false) at src/login/logind-action.c:36
36 in src/login/logind-action.c
(gdb) bt full
#0
This looks like an effect of
http://cgit.freedesktop.org/systemd/systemd/commit/?id=ed4ba7e4f65215.
This introduced logic which deliberately checks for a closed lid and
suspends the machine again, to guard against wakeups which happen when a
laptop lid is closed (and the machine is potentially
At this point we have two options:
(1) fix the kernel or hardware to not claim that there's a closed lid
(2) disable that safety feature and cause some laptops to burn in your bag again
If possible, I'd like to keep this and fix (1), but if this turns out to
affect too many machines we might
The log shows that something requests the suspend over D-Bus. The most
probable candidate for this is logind. After this happens, can you
please copypaste the output of journalctl -f -b -u systemd-logind
here? That should show key presses and which buttons it listens to.
To confirm that it's
journalctl -f -b -u systemd-logind
-- Logs begin at Tue 2015-03-31 09:36:25 BST. --
Mar 31 09:36:26 skylake systemd[1]: Starting Login Service...
Mar 31 09:36:26 skylake systemd-logind[671]: New seat seat0.
Mar 31 09:36:26 skylake systemd-logind[671]: Watching system buttons on
/dev/input/event3
The HandleLidSwitch=ignore stops the box from suspending:
$ uptime
09:50:25 up 5 min, 2 users, load average: 0.00, 0.00, 0.00
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Debugging notes:
- I see tons of Refusing operation, as it is turned off in the logs
now, which is due to the disabled HandleLidSwitch (before it was
Suspending...)
- I see no event at all in evtest
- I believe stopping acpid does not help, I still see the Refusing
operation... messages from
Ah, ok; Some more ideas:
- sudo systemctl stop acpid, to rule out acpid and acpi-support
- install evtest and run sudo evtest, select the lid switch, and
check if you actually get an event after ~ 3 minutes? I don't actually
expect one, as logind should then log a Lid closed. event which it
Interesting.. so logind does *not* log a button event; here I get
something like
Mär 31 11:04:09 donald systemd-logind[805]: Power key pressed.
on a button event. Can you check if the bug happens:
1) if you just log into VT1 after boot, not into X, and run sudo
systemctl stop lightdm
2)
I'm actually running vivid server on this box, so I don't have a unity
session running.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1438301
Title:
desktop machine
Lowering severity a bit. This only affects a particular piece of yet
unreleased hardware, and thus it isn't very widespread.
** Changed in: systemd (Ubuntu)
Importance: Critical = High
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
** Changed in: systemd (Ubuntu)
Importance: Undecided = Critical
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1438301
Title:
desktop machine suspends with systemd
13 matches
Mail list logo
