SUMMARY: GNOME startup issues

[Joe Marcus Clarke]

On 7/12/10 4:31 PM, Kevin Oberman wrote:
>> 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.

What you're seeing in the session details is expected.  The patches had
a noticeable improvement for me when GNOME was started from startx.  Run
a ktrace of the polkitd process as root, then try and add a new applet
to the panel.  When you get the add applet dialog, stop the ktrace, and
post the dump output.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team	::	gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome