Red Hat Bugzilla – Bug 1002782
1.6.0-1 lightdm-gtk-greeter segfaults if session last used is uninstalled (and has a silly cache location)
Last modified: 2013-11-10 01:04:52 EST
Description of problem:
When using lightdm-gtk-greeter, if, while no one is logged into the graphical console, you uninstall the windows manager (xfce4/gnome/cinnamon/etc.) that was last invoked by the greater, it goes into segfault loopy land.
And it caches such info in a silly place.
Version-Release number of selected component (if applicable):
Hopefully "very" given the steps below.
Steps to Reproduce:
yum -y install xfce4-session lightdm-gtk
systemctl disable gdm # or whatever the current display manager is
systemctl enable lightdm # use lightdm instead
# select xfce4 at the top right of the screen (they moved it in 1.6)
# open up a TTY console (Ctrl-Alt-F2)
yum -y remove xfce4-session
# watch as lightdm-gtk-greeter repeatedly falls all over itself
Aug 29 19:56:40 adrastea kernel: [12565.171691] lightdm-gtk-gre: segfault at 7fffd46ccff8 ip 00007fecf534e374 sp 00007fffd46ccff0 error 6 in libc-2.17.so[7fecf52d2000+1b6000]
Aug 29 19:56:41 adrastea kernel: [12567.074297] lightdm-gtk-gre: segfault at 7fff9a725ff8 ip 00007f36ed4eb374 sp 00007fff9a725ff0 error 6 in libc-2.17.so[7f36ed46f000+1b6000]
Aug 29 19:56:43 adrastea kernel: [12568.989247] lightdm-gtk-gre: segfault at 7fffeb483fb0 ip 00007f22bf26b363 sp 00007fffeb483fa0 error 6 in libc-2.17.so[7f22bf1ef000+1b6000]
Aug 29 19:56:45 adrastea kernel: [12570.905937] lightdm-gtk-gre: segfault at 7fff8aec8fb0 ip 00007f27be072363 sp 00007fff8aec8fa0 error 6 in libc-2.17.so[7f27bdff6000+1b6000]
Aug 29 19:56:47 adrastea kernel: [12572.835317] lightdm-gtk-gre: segfault at 7fffbf1affa0 ip 00007f63b07dc363 sp 00007fffbf1aff90 error 6 in libc-2.17.so[7f63b0760000+1b6000]
Aug 29 19:56:49 adrastea kernel: [12574.739749] lightdm-gtk-gre: segfault at 7fff61627fd0 ip 00007f34406c3363 sp 00007fff61627fc0 error 6 in libc-2.17.so[7f3440647000+1b6000]
The greeter starts so the computer is usable by the non-technical user.
The workaround is:
1) reinstall the last used windows manager, reboot, login using another manager, and the remove the one just reinstalled and then reboot
2) delete the file /var/log/lightdm/.cache/lightdm-gtk-greeter/state (which is a silly place to cache state information)
The state file is simply this:
While tracking this down I also saw mention that the same thing happens if you delete the last user that logged in, but I haven't tested that so am only reporting the last-session issue for now.
Of course, you can replace both the "reboot"s in the steps to reproduce by entering the following in a TTY session:
which may or may not be faster depending upon how fast you type.
Created attachment 809239 [details]
Here is the fix for the last_session segfault issue.
I've tested this in normal circumstances, and it works as expected. Please test if possible.
Looks good here. I rebuilt the RPM with included patch, telinit 3, yum install newrpm, telinit5, all is happy. I then telinit 3, yum install oldrpm, telinit 5 and it goes back to segfault loopy land. So that solves the segfault issue.
The issue of being a stupid place to store a state file remains, but that can be dealt with later I guess (I'd think that /var/cache/lightdm/lightdm-gtk/state would be a preferable location if only because it isn't in a .hidden folder in the log directory but one thing at a time).
Thanks Robert. Hopefully this can go to testing (or wherever it goes next).
Jack, in openSUSE the state file is in: /var/lib/lightdm/.cache/lightdm-gtk-greeter/state, so I guess this can be tuned.
I'm happy that the patch works. This also works well in openSUSE, just to make it clear :)
ah, lightd.conf lies! it claims the default location is:
looks like we can fix at least 2 problems at once here. :)
Oh geesh, so we run lightdm as lightdm user with passwd entry:
and these items use g_get_user_cache_dir calls, guess where those go? :-/
/* If not running as root write output to directories we control */
if (getuid () != 0)
default_log_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "log", NULL);
default_run_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "run", NULL);
default_cache_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "cache", NULL);
ick, ick, ick. Robert, do you know how opensuse handles this? set a better lightdm homedir, or set these explicitly in lightdm.conf (or other)?
Yep, it's based on /etc/passwd:
suse-machine:~ # cat /etc/passwd|grep light
Well I guess one bug turned into two bugs.
But does it work if cache-directory is set in lightdm.conf ? Meaning does it take the conf?
Hrm, I thought it would, but explicitly adding to lightdm.conf:
but the stuff under /var/log/lightdm/ still seems to get created and used. :(
Sorry for my rambling, but ultimately it looks like that previous stuff is not used by lightdm-gtk-greeter :
state_dir = g_build_filename (g_get_user_cache_dir (), "lightdm-gtk-greeter", NULL);
g_mkdir_with_parents (state_dir, 0775);
state_filename = g_build_filename (state_dir, "state", NULL);
No idea why they chose to hard-code the use of g_get_user_cache_dir instead of grok'ing lightdm cache-directory key, but there you have it.
I'll change the default lightdm user home to be /var/lib/lightdm (instead of /var/log/lightdm), to be at least a little more sane (this will only affect new installs)
lightdm-gtk-1.6.1-2.fc20 has been submitted as an update for Fedora 20.
lightdm-gtk-1.6.1-2.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing lightdm-gtk-1.6.1-2.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
lightdm-gtk-1.6.1-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
lightdm-gtk-1.6.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.