Bug#1011523: systemd-logind: lightdm ignores keyboard input for the first 3 seconds

[Vincent Lefevre]

On 2022-06-27 16:11:33 +0200, Vincent Lefevre wrote:
> cventin:~> systemd-analyze blame
> 10.812s NetworkManager-wait-online.service
[...]
> but the machine has 12 cores and I don't see a relation with
> systemd-logind.

Masking NetworkManager-wait-online.service doesn't solve the issue.

On 2022-06-27 15:39:51 +0200, Vincent Lefevre wrote:
> I'm wondering whether it could be related to this change:
> 
>         Changes in udev:
> [...]
>         * udevadm trigger gained a new --prioritized-subsystem= option to
>           process certain subsystems (and all their parent devices) earlier.
> 
>           systemd-udev-trigger.service now uses this new option to trigger
>           block and TPM devices first, hopefully making the boot a bit faster.
> 
> Also, I have plymouth installed on this machine. I should probably
> try without it to see if this makes a difference.

Uninstalling plymouth makes the boot faster, and in particular,
the display manager starts earlier, and I need to wait even more
before I can use the keyboard (there is still this 10-second
delay that appears in the logs).

However, reverting the change in systemd-udev-trigger.service by adding
/etc/systemd/system/systemd-udev-trigger.service with older contents
(from Debian/stable) as follows

--- /lib/systemd/system/systemd-udev-trigger.service    2022-06-02 20:07:11.000000000 +0200
+++ /etc/systemd/system/systemd-udev-trigger.service    2022-06-29 15:30:37.203967091 +0200
@@ -19,4 +19,5 @@
 [Service]
 Type=oneshot
 RemainAfterExit=yes
-ExecStart=-udevadm trigger --type=all --action=add --prioritized-subsystem=block,tpmrm
+ExecStart=udevadm trigger --type=subsystems --action=add
+ExecStart=udevadm trigger --type=devices --action=add

restores the old behavior. But I can see a 6-second freeze, e.g. on 2 tests:

Jun 29 15:36:57 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:36:57 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:37:03 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:37:03 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:37:03 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

and

Jun 29 15:38:02 cventin systemd[1]: Started Network Time Synchronization.
Jun 29 15:38:02 cventin systemd[1]: Reached target System Time Set.
Jun 29 15:38:08 cventin kernel: sr 2:0:0:0: Attached scsi generic sg0 type 5
Jun 29 15:38:08 cventin kernel: sr 3:0:0:0: Attached scsi generic sg1 type 5
Jun 29 15:38:08 cventin kernel: sd 6:0:0:0: Attached scsi generic sg2 type 0

Note that these "Attached scsi generic" messages occur only 1 second
after the boot without the change in systemd-udev-trigger.service, so
I'm wondering about the cause.

So it is possible that the new --prioritized-subsystem=block,tpmrm
option in systemd-udev-trigger.service introduced a side effect that
"fixes" the freeze (or was there a good reason for this freeze?) and
made an old keyboard issue appear, while it was previously hidden by
the freeze.

-- 
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)