Re: [gdm-list] gdm > 2.20 and SunRay

[Meik Hellmund <Meik Hellmund math uni-leipzig de>]

Brian,

many thanks for your detailed response. Should we continue this discussion 
in gdm-list or in sunray-users list? 

Brian Cameron <brian cameron oracle com> wrote:
> > We observed that the 57 gconfd daemons somehow  blocked each other(?)
> > (status "D" in the process list) and the  load factor of the
> > server was increasing to 50, then to over 100.
> > The gconfd user cache, /var/lib/gdm/.gconfd/saved_state, grew to>  100MB.
> 
> GDM 2.31.2 had some fixes to solve some issues with GConf not working
> well.  However, this fix only works if you are using GConf 2.31.3 or
> later (or if you build an earlier version of GConf with the attached
> patch).  Note you need to rebuild GDM after installing GConf built with
> this patch.
> 
> > There seems to be a basic problem: Gnome was never intended to be run in
> > this way: many sessions *belonging to the same user*. If several gconfd
> > daemons start to write to the same saved_state file, the result is
> > broken nonsense and the daemons which start reading this file get stuck.
> 
> This is very much like the issue that was fixed building GDM with GConf
> 2.31.3 or later, so this may be your issue.  Note the bug report, it
> sounds a lot like your problem:
> 
>    https://bugzilla.gnome.org/show_bug.cgi?id=594818
> 

This bug&patch is about the $HOME/.gconf directory. After updating my gconfd from 
2.28 to 2.32 this works for me and I have now a per-session .gconf directory 
$HOME/$ENV_GDM_SEAT_ID/.gconf
That's good. 
But there is still only one $HOME/.gconfd directory and only one
$HOME/.gconfd/saved_state cache file.

So I am afraid the problem with this cache file persists. Is it possible to configure 
gconfd not to read/write this file? As I understand, it is only a kind of cache for 
the content of the .gconf directory.

Meik

-- 
Meik Hellmund
Mathematisches Institut, Uni Leipzig
e-mail: Meik Hellmund math uni-leipzig de
http://www.math.uni-leipzig.de/~hellmund