Hi,
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 -- Meik Hellmund Mathematisches Institut, Uni Leipzig e-mail: meik.hellm...@math.uni-leipzig.de http://www.math.uni-leipzig.de/~hellmund _______________________________________________ SunRay-Users mailing list SunRay-Users@filibeto.org http://www.filibeto.org/mailman/listinfo/sunray-users