Bug#961146: systemd-logind sometimes ignores a systemd-inhibit lock

[Vincent Lefevre]

On 2020-05-22 23:53:58 +0200, Michael Biebl wrote:
> This is strange. Something is triggering the start of systemd-logind

What do you mean by "start of systemd-logind"?

On my machine, systemd-logind is started early at boot time and
never quits.

> (via D-Bus most likely). My educated guess is, that it is actually this
> process, which triggers the suspend, not logind itself.

But if the lid is not closed when I change the VT, the system
is not suspended.

And if I'm on a VT that is different from the one where
systemd-inhibit has been run and I close the lid, the system
is suspended.

> Remember when I initially said, that logind provides the mechanism and
> the policy is supposed to be proved by something else (usually the
> desktop environment).

A part of the policy is in logind, isn't it? I mean that
/etc/systemd/logind.conf has an option "HandleLidSwitch",
which I haven't modify, so that it is the default "suspend".
The suspend is just supposed to be blocked by an inhibitor,
which is also part of logind.

Note also that when I did the test, there was no desktop environment,
no X server, just 2 VTs involved. Which part of the system is in
charge of the VTs, then?

If I understand correctly, the suspend is done via the call of
manager_handle_action() in "login/logind-action.c". It would
be interesting to know the values of m and inhibit_key. But
according to what is logged, it seems that the call can only
be done via

        manager_handle_action(manager, INHIBIT_HANDLE_LID_SWITCH, handle_action, manager->lid_switch_ignore_inhibited, is_edge);

in button_lid_switch_handle_action(); otherwise I would have
got another message before "Suspending...". So inhibit_key
would have the expected value. But I'm wondering about
manager; if it is not constant, this seems to be wrong
(as the inhibitors are associated with it).

Then, concerning button_lid_switch_handle_action(), there are
2 calls:

1. From button_recheck(), and it seems that this is what is called
   when I change the VT while the lid is already closed.

2. From button_dispatch(). The button_lid_switch_handle_action()
   call is preceded by "Lid closed.", which is what I get when
   I close the lid. And if I'm on a "wrong" VT, the system will
   be suspended.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)