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): lightdm-gtk-1.6.0-1.fc19.x86_64 How reproducible: 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 reboot # select xfce4 at the top right of the screen (they moved it in 1.6) # login # logout # open up a TTY console (Ctrl-Alt-F2) # login yum -y remove xfce4-session reboot # watch as lightdm-gtk-greeter repeatedly falls all over itself Actual results: (snipped) Aug 29 19:56:40 adrastea kernel: [12565.171691] lightdm-gtk-gre[10655]: 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[10680]: 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[10705]: 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[10730]: 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[10755]: 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[10780]: segfault at 7fff61627fd0 ip 00007f34406c3363 sp 00007fff61627fc0 error 6 in libc-2.17.so[7f3440647000+1b6000] (snipped) Expected results: The greeter starts so the computer is usable by the non-technical user. Additional info: 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: [greeter] last-user=slick last-session=xfce 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: telinit 3 telinit 5 which may or may not be faster depending upon how fast you type.
Created attachment 809239 [details] lightdm-gtk-greeter-fix-segfault-when-last_session-is-invalid.patch 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: #cache-directory=/var/cache/lightdm looks like we can fix at least 2 problems at once here. :)
Oh geesh, so we run lightdm as lightdm user with passwd entry: lightdm:x:992:990::/var/log/lightdm:/sbin/nologin and these items use g_get_user_cache_dir calls, guess where those go? :-/
In particular, /* If not running as root write output to directories we control */ if (getuid () != 0) { g_free (default_log_dir); default_log_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "log", NULL); g_free (default_run_dir); default_run_dir = g_build_filename (g_get_user_cache_dir (), "lightdm", "run", NULL); g_free (default_cache_dir); 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 lightdm:x:490:490:LightDM daemon:/var/lib/lightdm:/bin/false :) 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: log-directory=/var/log/lightdm run-directory=/var/run/lightdm cache-directory=/var/cache/lightdm 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); g_free (state_dir); 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. https://admin.fedoraproject.org/updates/lightdm-gtk-1.6.1-2.fc20
lightdm-gtk-1.6.1-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lightdm-gtk-1.6.1-2.fc19
Package lightdm-gtk-1.6.1-2.fc20: * 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: https://admin.fedoraproject.org/updates/FEDORA-2013-18585/lightdm-gtk-1.6.1-2.fc20 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.