SUMMARY: GNOME startup issues

[Kevin Oberman]

> Date: Mon, 12 Jul 2010 12:41:28 -0400
> From: Joe Marcus Clarke <marcus at freebsd.org>
> 
> On 7/12/10 11:16 AM, Kevin Oberman wrote:
> >> Date: Mon, 12 Jul 2010 11:05:35 -0400
> >> From: Joe Marcus Clarke <marcus at freebsd.org>
> >>
> >> On 7/12/10 9:35 AM, Kevin Oberman wrote:
> >>>> Date: Sat, 10 Jul 2010 13:39:48 -0400
> >>>> From: Joe Marcus Clarke <marcus at freebsd.org>
> >>>> Sender: owner-freebsd-gnome at freebsd.org
> >>>>
> >>>> Okay, I have been spending time trying to recreate the problems people
> >>>> have been reporting with GNOME.  The problems are:
> >>>>
> >>>> * polkit-gnome-authentication-agent-1 crashes at startup
> >>>> * gnome-panel takes too long to start
> >>>> * Workspace Switcher does not work
> >>>>
> >>>> Sadly, I was unable to recreate what I would consider any problems.  I
> >>>> tested the following configurations:
> >>>>
> >>>> * FreeBSD i386 RELENG_8 from July 4 with ports from July 4
> >>>> * FreeBSD i386 -CURRENT from July 4 with ports from July 4
> >>>> * FreeBSD amd64 -CURRENT from July 5 with ports from July 5
> >>>> * FreeBSD i386 RELENG_8 from June 17 with ports from June 18 (in VMWare
> >>>> Fusion 3.0 on a Mac)
> >>>>
> >>>> I tested by starting GNOME from GDM and using startx.  My ~/.initrc has
> >>>> simply this:
> >>>>
> >>>> #!/bin/sh
> >>>>
> >>>> exec ck-launch-session gnome-session
> >>>>
> >>>> My locale is en_US.UTF-8.  I have procfs mounted, and I can perform:
> >>>>
> >>>> ping `localhost`
> >>>>
> >>>> Successfully.  I am not running ANY firewalls, and I have not enabled
> >>>> any blackholes for TCP or UDP.
> >>>>
> >>>> When I run GNOME from startx, I do see a delay of about 10 seconds while
> >>>> waiting for the panel to appear.  This is because gnome-panel is trying
> >>>> to contact GDM to determine if shutdown/reboot support is enabled.  This
> >>>> delay is expected in a startx configuration.
> >>>>
> >>>> Workspace Switcher has always worked for me.  I tried switching
> >>>> workspaces with the keyboard shortcut and by clicking on the space in
> >>>> the lower panel.  Both worked.  I was also able to bring up properties,
> >>>> and add an additional workspace.
> >>>>
> >>>> I was able to see a problem with polkit-gnome-authentication-agent-1 in
> >>>> ONE instance.  A core was produced.  This problem seems to occur when
> >>>> GDM switches the user to the logged in user.  I didn't notice any other
> >>>> problems related to this, though.
> >>>>
> >>>> For those still seeing workspace switch problems, rebuild gnome-panel
> >>>> with debugging symbols, then bind gdb to workspace switcher, and get a
> >>>> backtrace when it appears to be hung up.  That's after making sure all
> >>>> of the above is inline as much as possible with my test machines.
> >>>
> >>> I patched and re-built consolekit, re-booted and re-started Gnome. I see
> >>> no changes in behavior. I see a delay in the panel start and attempting
> >>> to add to a panel results in a panel freeze for exactly 25 seconds
> >>> during which the panel is completely frozen, including the portion of the
> >>> popup menu showing most of the selected "Add to Panel..." item. After
> >>> exactly 25 seconds, the panel re-draws properly and the Add to Panel
> >>> window appears. (The individual applets DO update, though.)
> >>>
> >>> There is no change in this from pre-patch system.
> >>>
> >>> I do see one change which may or may not be a result of the patch. My
> >>> netspeed applet crashes immediately and attempting to re-add it results
> >>> in "The panel encountered a problem while loading
> >>> "OAFIID:GNOME_NetspeedApplet"." 
> >>>
> >>> Again, this may not be tied to the consolekit applet as it has been a
> >>> bit unstable since I updated to 2.30, but it seems completely broken
> >>> since the patch.
> >>
> >> What does ck-list-sessions report?
> >> ck-list-sessions
> > Session1:
> > 	unix-user = '9381'
> > 	realname = 'Kevin Oberman'
> > 	seat = 'Seat1'
> > 	session-type = ''
> > 	active = FALSE
> > 	x11-display = ':0'
> > 	x11-display-device = 'ttyv0'
> > 	display-device = 'ttyv0'
> > 	remote-host-name = ''
> > 	is-local = TRUE
> > 	on-since = '2010-07-12T13:15:46.554682Z'
> > 	login-session-id = ''
> 
> Are you sure you applied the patch correctly, rebuilt, and reinstalled?
>  The x11-display-device should NOT be ttyv0 anymore, and the session
> should be active.

I have confirmed that the patch installed cleanly, now. It still seems
to make no difference. Yes, I re-booted after the installation. I still have:
Session1:
	unix-user = '9381'
	realname = 'Kevin Oberman'
	seat = 'Seat1'
	session-type = ''
	active = TRUE
	x11-display = ':0'
	x11-display-device = '/dev/ttyv8'
	display-device = 'ttyv0'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2010-07-12T20:03:35.364034Z'
	login-session-id = ''

I have checked the contents of ck-collect-session-info.c and they have
been patched. ck-get-x11-display-device is present in files and is
patched. I have confirmed that /usr/local/sbin contains all of the
freshly built files.

I am at a loss to explain this.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751