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):
Steps to Reproduce:
1. Change Language at GDM login screen
2.it will show screen to restart Login Screen
3. Press "Yes"
only Mouse shown, but screen not available back
GDM login screen should be back
*** 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.
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));
2884: whack_greeter_and_slave_fds ();
2886: slave_fd_out = pipe2;
2887: greeter_fd_out = pipe1;
2888: greeter_fd_in = pipe2;
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
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:
if you want to try it out.
That build works for me.
Thanks, works for me too. :)