Bug 1323173

Summary: X crashes when trying to unlock
Product: Red Hat Enterprise Linux 7 Reporter: Paul-Antoine Arras <listes>
Component: xorg-x11-serverAssignee: Adam Jackson <ajax>
Status: CLOSED WONTFIX QA Contact: Desktop QE <desktop-qa-list>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.2CC: listes
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-15 07:40:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Xorg log with crash info none

Description Paul-Antoine Arras 2016-04-01 12:42:09 UTC
Created attachment 1142550 [details]
Xorg log with crash info

Description of problem:
Xorg crashes when trying to unlock the session.

Version-Release number of selected component (if applicable):
Name                : xorg-x11-server-Xorg
Architecture        : x86_64
Version             : 1.17.2
Revision            : 10.el7

How reproducible:
Happens from time to time, approximately once a week.

Steps to Reproduce:
1. Lock screen
2. Enter password to unlock
3. Hit enter

Actual results:
Hangs on verifying password.
All inputs are frozen. The mouse can be moved but clicking has no effect.
The machine is still reachable via ssh but the only solution seems to be killing X.

Expected results:
Session unlocked.

Additional info:
The relevant error in Xorg log is:
"(EE) [mi] EQ overflowing.  Additional events will be discarded until existing events are processed."
followed by the backtrace.

Comment 2 Adam Jackson 2016-08-17 19:54:05 UTC
The backtrace shown here is stuck waiting for getpwnam() to finish, because (I assume) we're trying to add the acl rule allowing the authenticated user to add the screen. Thing is, gdm doesn't _do_ that on unlock, just at server setup. So I think what's actually happening is, the server _is_ really crashing on unlock for some reason, the log you've attached here is from the server launched to replace it, and the stall in getpwnam is because your network config has changed from under you and your NIS server or whatever is no longer accessible.

There's not a lot X can do about the network going away from under it, but if it really is crashing on unlock that can be fixed. When this occurs, do you see a /var/log/Xorg.0.log.old file with a real crash backtrace at the end?

Comment 3 Paul-Antoine Arras 2016-08-29 20:24:15 UTC
Thanks Adam for looking into this and sorry for not replying before.
I have actually been unable to reproduce the bug for the past few weeks. Maybe a recent update have managed to fix it. If it reappears I'll let you know, but I think the bug report can be closed for now.

Comment 5 RHEL Program Management 2020-12-15 07:40:44 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.