screen not consistently locking when lid is closed

It looks like <email address hidden> may be to blame here. To be sure, please delete all local extensions:

  cd ~/.local/share/gnome-shell
  rm -rf extensions

and then log in again.

Two questions:

1) It's not clear to me how <email address hidden> can be at fault when it's not compatible with the GNOME version in kinetic so it's not enabled.

2) For my own edification can you tell me how you determined that extension might be at fault, so I can repeat those troubleshooting steps myself in the future before reporting an issue?

Extensions cause most gnome-shell bugs so removing them is always the first thing that needs to be tried.

This setting shown in the above attachments also reminded me of that:

b'org.gnome.shell' b'enabled-extensions' b"['multi-volume@tigersoldier', '<email address hidden>', '<email address hidden>', '<email address hidden>']"

P.S. Disabled extensions can still cause bugs, because disabling is voluntary and many extensions don't disable "cleanly". That's why we always ask people to start by deleting the extensions.

1) I am able to reproduce this issue after removing Allow Locked Remote Desktop and restarting my computer, though again, it is intermittent so I can't reproduce it every time.

2) I am somewhat confused by this: "disabling is voluntary and many extensions don't disable 'cleanly'". Note that Allow Locked Remote Desktop wasn't disabled by me, it was disabled by the shell because it's not marked compatible with Kinetic's GNOME version. Surely when the shell decides an extension is incompatible and disables it, that's not "voluntary" and the shell's code does not run?

That might be a different kind of "disabled", but still it's good to be cautious. My advice is based on having reviewed thousands of bug reports and in some cases finding that disabling an extension was not enough and it had to be deleted before the bug stopped happening.

Please remember to delete all nonstandard extensions including 'multi-volume@tigersoldier' and '<email address hidden>'.

The purpose of the extensions does not necessarily need to relate to locking. When the screen locks, gnome-shell disables/unloads all extensions. And then they get re-enabled at unlock. Each disable/enable relies on calling into the extension itself and trusting that it is not buggy in any way. The obvious problem there is that any extension designed for any purpose might break the lock/unlock/suspend/resume behaviour.

Removed night themes switcher, problem is still intermittently reproducible. Sometimes when I close the lid wait several seconds and open it the screen simply doesn't lock. Never happened before Kinetic as far as I know.

OK, please:

1. Delete all local extensions, at least temporarily.

2. Log in again.

3. Open a Terminal window and start this running:

   journalctl -f > recentlog.txt

4. Reproduce the bug.

5. Press Ctrl+C in the Terminal window.

6. Attach the resulting text file here.

Maybe also check for simpler explanations:

  gsettings get org.gnome.desktop.lockdown disable-lock-screen
  gsettings get org.gnome.desktop.screensaver lock-enabled
  gsettings get org.gnome.desktop.screensaver ubuntu-lock-on-suspend

I've seen reports of these being toggled without the owner's knowledge.

i have already removed all extensions that aren't part of Ubuntu.

Attached is recentlog.txt as requested. As you can see it locked successfully several times and then didn't lock the last time. I don't see anything in the log indicating why.

$ gsettings get org.gnome.desktop.lockdown disable-lock-screen
false
$ gsettings get org.gnome.desktop.screensaver lock-enabled
true
$ gsettings get org.gnome.desktop.screensaver ubuntu-lock-on-suspend
true

Thanks for that. Indeed the log shows the lid being closed without any locking near the end. That might be related to bug 1857392 which is clearly occurring at the same time. It also highlights that systemd is responsible for initiating the locking.

My first guess is that there is an inhibitor lock for "handle-lid-switch" in place which is blocking or delaying the screen lock.

Jonathan - Can you please enable debug level logging on systemd-logind.service by doing the following?

$ systemctl edit systemd-logind.service

In the editor, add a section like this:

 [Service]
 Environment=SYSTEMD_LOG_LEVEL=debug

Then reboot, and next time you experience this issue share the log:

$ journalctl -b -u systemd-logind --no-pager > systemd-logind.log

It is probably also worth sharing your logind.conf:

$ systemd-analyze cat-config systemd/logind.conf > logind.conf

When I configure my systemd to lock on lid switch, I do see this debug-level message:

Oct 12 16:19:45 six systemd-logind[1173]: Inhibitor GNOME Shell (GNOME needs to lock the screen) pid=2894 uid=1000 mode=delay started.

I am not sure exactly how GNOME handles locking the screen, but maybe the bug that Daniel pointed out (bug 1857392) is preventing GNOME from processing an Inhibitor DBus signal and locking the screen in a timely manner.

Bug 1857392 occurs on practically all machines every day so I recommend ignoring that one specifically. In comment #13 I think I was just pointing out there seems to be a common root cause if we can find out why/where bug 1857392 occurs so often.

[Expired for systemd (Ubuntu) because there has been no activity for 60 days.]