[gdm-list] gdm > 2.20 and SunRay


I am trying to get gdm 2.32 running on a Debian SunRay server using the
multi-seat patches from OpenSolaris: 
 - consolekit 0.4.3 + ConsoleKit-07-cores-srss.diff + ConsoleKit-06-ck-history.diff
 - gdm 2.32 + gdm-01-dynamic-display.diff + gdm-24-pamservice.diff
 - gdmdynamic script from OpenSolaris 

My test installation with two SunRay terminals worked quite ok.
There is a problem if someone kills the X-server of the Login screen
(say, by ctrl-alt-bksp-bksp). Then the Sunray stays in the infamous "26D"
state. But apart from that everything seemed fine.

But when we tried a larger installation, 57 SunRay terminals, we
got into serious trouble. 

One design decision of the new gdm > 2.20 is that now the login screen is a
full Gnome session, with running gconfd daemon, metacity windows manager
etc. etc. This gnome session belongs to the "gdm" user. 
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. 

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.

I send this to the sunray-users and the gdm list in the hope that someone
has some idea/experience.
Dear Oracle developer, did you observe similar problems with the new gdm and
Opensolaris? Did you add some more magic I am not aware of? 

Best wishes for 2011!


Meik Hellmund
Mathematisches Institut, Uni Leipzig
e-mail: Meik Hellmund math uni-leipzig de

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]