| Summary: | gnome-base/gdm broken occupied VT detection and keyboard activation | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jimmy.Jazz |
| Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ikelos, insanity5902, mike.delorme, pacho, picogeyer, rain, xmw |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| URL: | http://bugzilla.gnome.org/show_bug.cgi?id=498333 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | gdm-2.26.1-VT.patch | ||
we won't change the xdm init script because it is used by more than gdm alone so this is not an option. (In reply to comment #1) > we won't change the xdm init script because it is used by more than gdm alone > so this is not an option. > In that case apply the patch I propose. It preserves the delete_pid() in the parent process. /var/run/gdm.pid will be deleted before write_pid() is called from the child process :) (In reply to comment #1) or test the version of gdm with # gdmflexiserver --version gdmflexiserver 2.24.1 (In reply to comment #0) > hello, > > the gdm-2.24.0-fix-daemonize-regression.patch file has introduced a new bug > when gdm is daemonized. Hold on a sec, this patch file is an old one, it was updated last October[1] in the overlay. Could you sync and try again? (current version in the overlay is 2.25.1) 1. http://bugzilla.gnome.org/show_bug.cgi?id=550170 (In reply to comment #4) > Could you sync and try again? gdm 2.25.2 works now. I changed a bit the overlay ebuild and restored the original gentoo inittab. Still It could be a simple coincidence if gdm has chosen vt7 instead of the usual vt2 as it used to. For clarity, i'm using gentoo /etc/X11/gdm/PostSession/Default file. It isn't included in the modified ebuild. There is still an issue with the icons and background. They are displayed really late and after the menu has appeared on the screen. Besides, 3 menus are displayed in the bottom bar when a use is selected :) the modif, # diff -ruN ../../../layman/gnome/gnome-base/gdm/gdm-2.25.2.ebuild gdm-2.25.2-r1.ebuild --- ../../../layman/gnome/gnome-base/gdm/gdm-2.25.2.ebuild 2009-02-23 16:36:09.100955271 +0100 +++ gdm-2.25.2-r1.ebuild 2009-03-11 16:36:23.166242347 +0100 @@ -13,7 +13,8 @@ KEYWORDS="~amd64 ~x86" IUSE_LIBC="elibc_glibc" -IUSE="accessibility debug ipv6 gnome-keyring policykit selinux tcpd xinerama $IUSE_LIBC" +IUSE="accessibility debug ipv6 gnome-keyring policykit selinux tcpd xinerama +$IUSE_LIBC profile" # Name of the tarball with gentoo specific files GDM_EXTRA="${PN}-2.20.5-gentoo-files" @@ -65,6 +66,13 @@ pkg_setup() { G2CONF="${G2CONF} + --enable-schemas-install + --sysconfdir=/etc + --with-dmconfdir=/etc/X11/dm + --with-sysconfsubdir=X11/gdm + $(use_enable profile profiling)" + + G2CONF="${G2CONF} --disable-schemas-install --localstatedir=/var --with-xdmcp=yes @@ -109,11 +117,6 @@ fowners root:gdm /var/gdm fperms 1770 /var/gdm - # use our own session script - rm -f "${D}/etc/X11/gdm/Xsession" - exeinto /etc/X11/gdm - doexe "${gentoodir}/Xsession" - # add a custom xsession .desktop by default (#44537) exeinto /etc/X11/dm/Sessions doexe "${gentoodir}/custom.desktop" @@ -127,7 +130,6 @@ use gnome-keyring && sed -i "s:#Keyring=::g" "${gentoodir}"/pam.d/* dopamd "${gentoodir}"/pam.d/* - dopamsecurity console.apps "${gentoodir}/security/console.apps/gdmsetup" } pkg_postinst() { (In reply to comment #5) oops, disable-schemas-install isn't present in the ebuild i use (In reply to comment #4) Sorry, it still doesn't work well; if the vt is used by a getty or whatever, gdm is unstable and restart randomly. If an none allocated tty is used instead like the vt7, gdm will work better... The root cause of this bug has been reported upstream by the FreeBSD guys for a (different?) reason. Basically, openrc starts init services before initializing the VTs, and gdm thinks VT2 is free and occupies it. (In reply to comment #8) > The root cause of this bug has been reported upstream by the FreeBSD guys for a > (different?) reason. Basically, openrc starts init services before initializing > the VTs, and gdm thinks VT2 is free and occupies it. > I'm using the legacy gentoo baselayout 1.12.12. I still don't use openrc and xdm(gdm) is launched during init level 3 just before local.start the last init.d default service. So I believe gdm is simply ignoring the fact vts are already set up. Also, the issue has never appeared with older ebuilds and the vts should have already be launched since init level 2. (In reply to comment #9) > I'm using the legacy gentoo baselayout 1.12.12. I still don't use openrc and > xdm(gdm) is launched during init level 3 just before local.start the last > init.d default service. So I believe gdm is simply ignoring the fact vts are > already set up. Also, the issue has never appeared with older ebuilds and the > vts should have already be launched since init level 2. > Interesting. Then I guess GDM's VT-guessing code is broken. This requires investigation that I don't have the time to do, will someone volunteer? :) (In reply to comment #10) > (In reply to comment #9) > > I'm using the legacy gentoo baselayout 1.12.12. I still don't use openrc and > > xdm(gdm) is launched during init level 3 just before local.start the last > > init.d default service. So I believe gdm is simply ignoring the fact vts are > > already set up. Also, the issue has never appeared with older ebuilds and the > > vts should have already be launched since init level 2. > > > > Interesting. Then I guess GDM's VT-guessing code is broken. This requires > investigation that I don't have the time to do, will someone volunteer? :) > Mmm... then this is weird: in my case gdm-2.26 runs in vt2 only if xdm is launched at boot time (default runlevel) and, even in this case, only on the first login. If I remove xdm from the default runlevel and manually start it from vt1, gdm correctly detects the first 6 vts are in use and starts in vt7. If I have xdm in the default runlevel gdm starts in vt2, but if I login and logout, gdm goes automatically to vt7. So it seems a boot-only problem. *** Bug 263306 has been marked as a duplicate of this bug. *** *** Bug 215628 has been marked as a duplicate of this bug. *** Here's a workaround, it's a pain, but it is better then waiting for it to happen. Once you log in, go ahead and log back out out and then log in. It does the same thing as when it crashes, and loads on vt7 properly. In my case it looks like it is loading on vt2. I have the exact some logs and stuff as the guy in this posting on the forums http://forums.gentoo.org/viewtopic-t-750470.html Right now xdm is in the default runlevel, here are versions of the following, let me know if you need more. info gnome-base/gdm-2.26.0 USE="accessibility gnome-keyring tcpd" sys-apps/baselayout-2.0.0 sys-apps/openrc-0.4.3-r1 USE="ncurses pam unicode" (In reply to comment #14) > Here's a workaround, it's a pain, but it is better then waiting for it to > happen. > > Once you log in, go ahead and log back out out and then log in. It does the > same thing as when it crashes, and loads on vt7 properly. In my case it looks > like it is loading on vt2. I have the exact some logs and stuff as the guy in > this posting on the forums http://forums.gentoo.org/viewtopic-t-750470.html > > Right now xdm is in the default runlevel, here are versions of the following, > let me know if you need more. info > > gnome-base/gdm-2.26.0 USE="accessibility gnome-keyring tcpd" > sys-apps/baselayout-2.0.0 > sys-apps/openrc-0.4.3-r1 USE="ncurses pam unicode" > a more simply workaround, edit /etc/inittab and comment out line c2, #c2:2345:respawn:/sbin/agetty 38400 tty2 linux You will just lost one of the 7 ttys aka tty2 Created attachment 191067 [details, diff]
gdm-2.26.1-VT.patch
based on the patch attached to upstreams bug.
main difference is that settings are already loaded at the point where we need the info so calling ..._init for reading the settings again would trigger an assert.
(In reply to comment #16) > Created an attachment (id=191067) [edit] > gdm-2.26.1-VT.patch > > based on the patch attached to upstreams bug. Added to overlay as -r1, and finally things work, thanks Tiziano :-) Hello, I think this fix kills the switch user functionality. Every Xorg server instance gets invoked on vt7 instead of vt8, vt9 and so on. This locks up the the first Xorg process unrecoverable w/o xdm zap + reboot. I've encountered this at gem-2.28.2. Michael (In reply to comment #18) > I think Just checked. -2.26.1-broken-VT-detection.patch pins the Xorg instance to vt7 and definitely fucks up the working user switcher functionality. gdm-2.28 doesn't care which vt is free, Xorg w/o vt argument does this alone. And due to gdm beeing started during runlevel default initialization, tty2/vt2 is the first free one after tty1 with the startup output. In fact the agetty steals the tty from the Xorg server. Solutions like http://bugs.gentoo.org/show_bug.cgi?id=215628#c5 do not work any longer. gdm does not support FirstVT anymore. xorg-server-1.6.5/hw/xfree86/os-support/linux/lnx_init.c:145 uses VT_OPENQRY to qeury the kernel for a free vt. This dynamic race of Xorg instances for the terms is pritty tough. - could be possible to use vt2..6 during bootup to force X to vt7 - or juse use X on vt2... and let tty2..6 go with tty for emerg/maint. - or start /etc/init.d/xdm or /usr/bin/gdm from inittab. Everyone of the above possibilities is better than just kick the multi X session functionality on this os. my 2 cents. Please see http://bugs.gentoo.org/show_bug.cgi?id=312017#c9 for a new patch. |
hello, the gdm-2.24.0-fix-daemonize-regression.patch file has introduced a new bug when gdm is daemonized. open() is called by write_pid() and it uses both O_CREAT and O_EXCL flags. Also write_pid() will fail if the pid file exists. In fact there is no reason to call write_pid() in the parent process because in that case write_pid() called from the child process will always fail. The parent that call function as well will be the only one to be able to write its own id in /var/run/gdm.pid (if the file doesn't exist previously). As a result, When you want to stop the child you will try to kill an already exited parent process. Moreover, /etc/init.d/xdm script creates the pid file for you with the touch command. It isn't required because of the presence of delete_pid() in daemon.c. If you eliminate delete_pid() in main(), both gdm parent and child processes won't be able to open the pid file because of the /etc/init.d/xdm script. I suggest you not to create the pid file manually in the init xdm script and to suppress the write_pid() call in the gdm parent process. Also it is still a good idea to let the delete_pid() in daemon.c. # cat gdm-2.24.1-pid.patch --- daemon/main.c.orig 2009-03-03 23:06:14.871092103 +0100 +++ daemon/main.c 2009-03-03 23:17:37.484091650 +0100 @@ -665,8 +665,8 @@ } /* pid file */ - delete_pid (); - write_pid (); + delete_pid (); + //write_pid (); if (!no_daemon) { /* fork and write pid file with child's pid */ An other silly bug. The fact is gdm doesn't care about which vt will be used for Xorg. If a preallocated getty vt like the tty2 is used, gnome session will become unstable and you can even lose your keyboard input in a gnome terminal window or you session. If tty7 isn't used by Xorg as it should, the tty2 is always preferred. Like workaround, I have temporary commented out the getty line for tty2 in /etc/inittab. Reproducible: Always