Bug 20109 - gdm fails to start x11 when user logs off
Summary: gdm fails to start x11 when user logs off
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal critical
Target Milestone: ---
Assignee: GNOME maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-01-12 17:00 CET by Thierry Vignaud
Modified: 2020-09-09 18:27 CEST (History)
1 user (show)

See Also:
Source RPM: gdm-3.22.1-2.mga6
CVE:
Status comment:


Attachments

Description Thierry Vignaud 2017-01-12 17:00:54 CET
Description of problem:
Gdm fails to start up xserver when logging out of an autologin user.
Logs are filled with access errors such as:
systemd[31631]: Failed to open directory /var/lib/gdm/.local/share/systemd/user, ignoring: Permission denied
And then we can see:
gdm[30805]: GLib: g_hash_table_find: assertion 'version == hash_table->version' failed

The failure is the same whether gdm was started through dm.service or gdm.service

Version-Release number of selected component (if applicable):
gdm-3.22.1-2.mga6

How reproducible:
always

Steps to Reproduce:
1. autologin to some user
2. log off
3. gdm tries to start a new xserver but badly fails...
Marja Van Waes 2017-01-12 17:18:51 CET

CC: (none) => marja11
Assignee: bugsquad => gnome

Jani Välimaa 2017-02-25 20:05:23 CET

Component: New RPM package request => RPM Packages

Comment 1 Thierry Vignaud 2017-02-26 09:00:02 CET
The issue might be b/c gdm left some leftover processes:
there's a similar issue where gdm won't restart when told to do so with systemctl b/c there's runaway helper processes.
One has to manually killed those processes in order to be able to finally restart gdm
Comment 2 Aurelien Oudelet 2020-09-09 18:27:03 CEST
Against Mageia 6
Hi, thanks for reporting this bug.
We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there.
As a result we are setting this bug to RESOLVED:OLD

Status: NEW => RESOLVED
Resolution: (none) => OLD


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