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

[Brian Cameron <brian cameron oracle com>]

Meik:

On Solaris, we are using GDM 2.30.5 and ConsoleKit 0.4.1.  We have not
done much testing with ConsoleKit 0.4.2 so I am not sure if it works 
well.  If nothing else helps and if you are using 0.4.2, you might try
backing out to 0.4.1 and see if that helps (this may require using a
slightly older version of GDM such as 2.30.5 - not sure).

Note that the Solaris spec-files and patches are all here, so you can
see how ConsoleKit and GDM are built on Solaris.  We have done a lot
of Sun Ray testing, and people report it works well.

http://src.opensolaris.org/source/xref/jds/spec-files/branches/gnome-2-30/

Note the patches we apply in the "patches" subdirectory.  You should
at least use the following patches:

- ConsoleKit-01-ck-dynamic.diff,
- ConsoleKit-02-add-sunray-type.diff
- gdm-01-dynamic-display.diff

Also, Sun Ray depends on the gdmdynamic script which is in the
ext-sources directory.  This is just a wrapper around ck-seat-tool.
Our plan was to fix SRSS to just use ck-seat-tool directly once the
above patches go upstream, but that has obviously not happened yet.

Note that the GDM and ConsoleKit patches are also here:

  https://bugzilla.gnome.org/show_bug.cgi?id=536355
  https://bugs.freedesktop.org/show_bug.cgi?id=19333

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

One thing that will cause GDM to leave a Sun Ray display in an
"unmanaged" "26D" state is if the slave crashes.  It would be good to
turn on GDM debug by editing /etc/gdm/custom.conf and adding a line
that says "Enable=true" after the line that says "[debug]" so it looks
like this:

[debug]
Enable=true

Then restart the GDM service or reboot, then recreate the problem and
there should be verbose debug messages at the end of the syslog file
(/var/log/messages or /var/adm/messages depending on your system).
These messages might help to track down the problem.  If there is a
crash, GDM will put a stack trace in the syslog.  Since we have not
done much testing with any versions of GDM with Sun Ray since 2.30.5,
there may be issues using later versions that might need attention.

Also would be good to check the logs in /var/log/gdm to see if there
are any errors there.

Feel free to share any output with me and I can try to help diagnose
if the error is not obvious to you.

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

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

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

I do not think there is too much magic.  Most problems that Sun Ray has
with GDM are general issues (e.g. the GConf issue I mention above which
was fixed in 2.31.3 also affected XDMCP), and we have worked hard to
get features upstream to support Sun Ray.

However, the other GDM maintainers have not yet approved the 3 patches
listed above (ConsoleKit-01-ck-dynamic.diff,
ConsoleKit-02-add-sunray-type.diff, gdm-01-dynamic-display.diff), so it
is currently necessary to rebuild with these to get Sun Ray support with
the new ConsoleKit/GDM.

Brian

--- GConf-2.31.1/gconf-2.0.pc.in-orig	2010-04-28 20:58:42.331252962 -0500
+++ GConf-2.31.1/gconf-2.0.pc.in	2010-04-28 21:01:09.731981994 -0500
@@ -3,7 +3,7 @@ exec_prefix= exec_prefix@
 libdir= libdir@
 includedir= includedir@
 gconf_serverdir= libexecdir@
-
+gconf_defaultpath= gconfdefaultpath@
 
 Name: gconf
 Description: GNOME Config System.
--- GConf-2.31.1/configure.in-orig	2010-04-28 20:58:31.074078024 -0500
+++ GConf-2.31.1/configure.in	2010-04-28 21:02:51.588922513 -0500
@@ -110,7 +110,9 @@ if test "x${with_sysconfsubdir}" != "x";
 else
   sysgconfdir='${sysconfdir}'
 fi
+gconfdefaultpath="$sysconfdir/$with_sysconfsubdir/$MAJOR_VERSION/path"
 AC_SUBST(sysgconfdir)
+AC_SUBST(gconfdefaultpath)
 
 dnl Save flags to aclocal
 ACLOCAL="$ACLOCAL $ACLOCAL_FLAGS"