Description of problem: After changing Language for GDM, it shows message showing "Do you wish to restart the login screen with chosen Language", Pressing "YES", it showing only mouse, but GDM hanged and not restarted, only after killing it, it start again Version-Release number of selected component (if applicable): gdm-2.19.1-1.fc8 How reproducible: Everytime Steps to Reproduce: 1. Change Language at GDM login screen 2.it will show screen to restart Login Screen 3. Press "Yes" Actual results: only Mouse shown, but screen not available back Expected results: GDM login screen should be back Additional info:
*** Bug 246414 has been marked as a duplicate of this bug. ***
I found gdm is blocked in function call gdm_fdgetc (greeter_fd_in) in slave.c 5598 line. It seems not all of write peers of pipe greeter_fd_in was closed when shutdown gdmgreeter. So the gdm_fdgetc will be blocked instead of return EOF immediately. I guess it should close slave_fd_out before call gdm_fdgetc.
This problem has been fixed in HEAD version in upstream.
Yup, thanks for the fix Huang!
Reopening, since we really need to do something for this for F8. Still see this with gdm-2.20.0-1.fc8.
This bug does exist in upstream's gdm. It is just in our version. I found gdm-2.19.1-reset-pam.patch causes this problem. What is this patch for?
This bug is already fixed in rawhide. I started to build it right after closing the bug report, and to my surprise mclasen did too. he typed faster. reset-pam is for smartcards.
Sorry, I'd really like to keep this open until I can no longer reproduce. It is still happening to me after again updating to the latest rawhide with gdm-2.20.0-3.fc8. I will try a fresh install now.
Sorry for the typo in comment #6 . It should be: This bug does not exist in upstream's gdm. :) I check the code of latest rawhide. It still has this problem. gdm keep the output peer of pipe in daemon/slave.c, line 2883 . It is different from upstream's version because of one our patch. Upstream gdm just closes pope2[1]. It cause this bug in our version. If we want to keep the output peer of pipe(slave_fd_out), we should close it before restart the gdmgreet. 2883: VE_IGNORE_EINTR (close (pipe1[0])); 2884: whack_greeter_and_slave_fds (); 2885: 2886: slave_fd_out = pipe2[1]; ~~~~~~~~~~~~~~~~~~~~~~~ 2887: greeter_fd_out = pipe1[1]; 2888: greeter_fd_in = pipe2[0];
Hmm, well the pipe fd *should* be close on exec, and it should get automatically closed by g_spawn when running the language dialog. I'll probably have to reproduce this and investigate more, unless you want to. It's on the Blocker list, so it won't get forgotton before release.
I can confirm that it still hangs
I am analyzing the patch (gdm-2.19.5-reset-pam.patch) that causes this bug. Who can tell me which bug the patch is for fixing ? I need more information about this patch.
Hi Huang, It's not fixing a bug, it's a patch that provides the ability to reset an active pam conversation (required for a RHEL5 feature).
*** Bug 307831 has been marked as a duplicate of this bug. ***
Still see this with rawhide-20070925 live i386 iso.. adding myself to CC.
Adam, should be fixed with this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=19834 if you want to try it out.
That build works for me.
Thanks, works for me too. :)