GNOME Bugzilla – Bug 662931
gdm 3.2 fails to start
Last modified: 2012-03-07 11:34:02 UTC
Created attachment 200167 [details] gdb output of t a a bt full when xorg starts, instead of the gdm greeter, i get a dark screen + busy cursor. /var/log/gdm/:0-greeter.log.0 does not exists (deleted old file...) /var/log/gdm/:0-slave.log is 0 bytes long. starting with the gdm daemon or through inittab has the same effect. (archlinux) if i start X with exec ck-launch-session gnome-session through xinitrc my session starts correctly (gnome-shell). i dont remember what update broke it. but it did work with 3.2 at some point. $ ps aux |grep gdm gdm 3846 0.0 0.0 2632 724 ? Ss Oct27 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session gdm 14238 0.0 0.0 2632 340 ? Ss 07:52 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session root 14327 0.0 0.2 16344 2440 ? Ssl 07:55 0:00 /usr/sbin/gdm-binary -nodaemon root 14331 0.0 0.3 19816 3556 ? Sl 07:55 0:00 /usr/lib/gdm/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 root 14333 0.0 1.0 29540 11044 tty7 Ss+ 07:55 0:00 /usr/bin/Xorg :0 -br -verbose -logverbose 7 -auth /var/run/gdm/auth-for-gdm-o2sbTq/database -no listen tcp vt7 gdm 14343 0.0 0.0 0 0 ? Zs 07:55 0:00 [dbus-launch] <defunct> gdm 14347 0.0 0.0 2632 344 ? Ss 07:55 0:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session tomas 14563 0.0 0.0 4328 820 pts/2 S+ 08:46 0:00 grep --color gdm Im attaching a gdb trace for gdm-simple-slave for more reference, some nice guy helped me do all this: https://bbs.archlinux.org/viewtopic.php?pid=1009227
if you do it again do you get the same backtrace? That backtrace looks like either 1) dbus-launch is stalling an never finishing or 2) you took the backtrace really quickly during boot before dbus-launch finished
posting a new backtrace since i dont know what makes it 'the same backtrace' 1. yes, this can stay like that for hours 2. i dont think this is the case. even if i did kill everything (init 3), and started from scratch, i waited a considerable amount of time for everything to settle.
Created attachment 200176 [details] second gdb trace
Okay, so you definitely seem to be afflicted by 1) not 2). Can you post a backtrace of dbus-launch since it's the thing that's stuck?
@Tomas for that you need to recompile dbus-core and dbus with debug symbols. read about it here: https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#One_package_settings_only
oh looking at your ps output in comment 0 dbus-launch isn't stuck it's dead, which is what we expect. So the question is, why is g_spawn_sync stuck in select()...
so i take it from comment 6 that a dbus backtrace is not needed?
Right, I don't think you would be able to get one anyway, since the process is already undead.
Have you upgraded your glib recently? This may be some sort of glib regression.
Looking in the GDM code, there's some weird looking to me. We use a child_setup_func that adjusts stdout/stderr to a log file, but that can't be right since we need to parse the dbus launch output from stdout. I must be misreading, but will have to take a closer look later.
downgraded glib2 which was recently upgraded from 2.30.0 to 2.30.1 (yet prior to breakage). still the same issue. - are there any config files i might have inadvertedly broken from a previous release of gdm? i did disable the power management plugin on gdm through dconf-editor. this is an old install which might carry some cruft from gnome2.
Tomas M.: Is this still a problem in a recent version?
no, this got fixed in some update. i cannot say which since its a server i update remotely.