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

[Brian Cameron <brian cameron oracle com>]

Meik:

> 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

This should make GConf behave better with GDM.

> $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.

I assume you mean /var/lib/gdm/.gconfd/saved_state cache file.  It isn't 
a problem for the /var/lib/gdm/.gconfd directory and other files
to exist, but the cache may be an issue if it grows too big.

I'd delete the file, and see if it grows too big again.  If you were
experiencing problems before, it may have been related to the fact that
GConf and GDM weren't integrated well.  Now that you've updated your
system so it is saving separate .gconf directories for each display, you
may find the issue with the cache goes away if you remove the version
that got too big.  Does this help at all?

If not, could you explain the symptoms of the problem in more detail?
How does the failure manifest itself, for example?  Any relating
message in log files?

> 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.

If you find that the cache grows too large frequently, it might be 
necessary to purge it.  You could perhaps do this on bootup, or in the
GDM Init script (/etc/gdm/Init/Default) which is run before GDM starts
the Xserver and any GUI's on a given display.  How quickly does it get
too big and start causing issues?

However, I think fixing your system to save the .gconf directory 
separatey per-display should just fix this problem.  But you may have
to erase the cache file that got too big since it perhaps grew too big
when you previously had your system misconfigured for multiple
GDM/GConf use.

Brian