Bug 1998356 - Screen Locking Failure "Lock was blocked by application"
Summary: Screen Locking Failure "Lock was blocked by application"
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gnome-shell
Version: 8.4
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-26 22:17 UTC by Brandon Clark
Modified: 2023-08-10 16:32 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-15 14:02:35 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-95387 0 None None None 2021-08-26 22:18:40 UTC

Description Brandon Clark 2021-08-26 22:17:20 UTC
Description of problem:
When attempting to lock screen, the following error is observed:
	“Lock was blocked by an application”

The line outputted by the messages log is the following:

	gnome-shell[22519]: pushModal: invocation of begin_modal failed
	gnome-shell[22519]: pushModal: invocation of begin_modal failed
	gnome-shell[22519]: error :Unable to lock: Lock was blocked by an application

Certain applications such as firefox an gnome-terminal are two applications that were observed by the customer this was opened for that could cause this behavior. It appears that the screen lock signal is even ignored wholesale in certain cases as it is not registered in dbus diagnostic output.

Version-Release number of selected component (if applicable):
gdm-3.28.3.39.el8.x86_64
libXi-1.7.10-1.el8.x86_64
gnome-shell-3.32.2-30.el8.x86_64
dbus-1.12.8-12.el8_4.2.x86_64


How reproducible:
Consistent

Steps to Reproduce:
	1)Install system via a kickstart with STIG implemented, though with FIPS disabled. Ensure 'use_nfs_home_dir is set to "on"'.
	2) Login
	3) Attempt to induce issue by idle or <Super>l combination while programs such as firefox or gnome-terminal are open.

Actual results:
	Error output 

Expected results:
	Screen locks successfully.

Additional info:
	I was unable to reproduce this behavior myself after considerable testing. This issue is evident in RHEL 7 as well, though customer confirmed they observed it in 8.

Comment 1 Florian Müllner 2021-08-27 11:29:13 UTC
The most likely reason is what the warning message says: An application has grabbed the keyboard or pointer (most probably because of an open (popup) menu).

Not locking the screen is the best we can do in that situation. The alternative leaves the user without a way to unlock the session in the best case, and sends the password to the application that holds the grab in the worst case.

So unless there's an indication that the failure is not triggered by an existing grab, this is WONTFIX/CANTFIX.

Comment 2 Steve Barcomb 2022-02-15 14:02:35 UTC
Marking this bug closed since we have not heard back for sometime and the customer case is closed.  If there is renewed interest in this bug please reach out to me directly.

-Steve


Note You need to log in before you can comment on or make changes to this bug.