[gdm-list] gdm > 2.20 and SunRay
- From: Meik Hellmund <Meik Hellmund math uni-leipzig de>
- To: sunray-users filibeto org, gdm-list gnome org
- Subject: [gdm-list] gdm > 2.20 and SunRay
- Date: Tue, 4 Jan 2011 14:54:25 +0100
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!
Mathematisches Institut, Uni Leipzig
e-mail: Meik Hellmund math uni-leipzig de
[Date Prev][Date Next
] [Thread Prev][Thread Next