This is weird.  What version of GDM are you using.  If you are using a 2.13 version, I'd recommend updating to the latest 2.13.0.8 release.  There have been lots of nasty gotchas in the 2.13 unstable builds, but I think 2.13.0.8 is far more stable than the previous releases.  It also has some nice fixes that make GDM more stable in general, and it also has better debug.

You should turn on debug in the GDM configuration (run gdmsetup and click on "turn on debug" in the Security tab).  Then restart GDM (gdm-restart) and the next time the problem happens, you will hopefully get some feedback about what caused the problem.  GDM debug goes to the system log.

I've finally figured out what triggers this bug.
gdm uses a file
/tmp/.gdm_socket
I would have problems at regular intervals because
tmpwatch would delete that file because its
timestamp doesn't get changed, even though the socket is used.

To fix this, gdm can check to see if the file disappears,
and if necessary, recreate it.  Another possibilty is
to prevent this from happening by touching the file when
it lauches gdmgreeter.

Thanks for tracking down the problem.  Can't tmpwatch be configured not to disrupt GDM?  I would accept a patch to make GDM recreate the file if it disappears.  It shouldn't be necessary for GDM to touch the file.  It seems bad for a program like tmpwatch to remove files it shouldn't.  Perhaps this is tmpwatch bug.  Perhaps it should be fixed so it knows not to delete GDM sockets files.

Yes, tmpwatch can be configured not to touch special files.
Recreating the socket when necessary would probably be
the best course of action.

As an immediate work around, I made the script that runs tmpwatch
touch the file first.

>I would accept a patch to make GDM recreate the file if it
>disappears.
Do you mean that I should write it?  I am not familiar with the code
for gdm at all.  I could try if necessary, but I don't know how
well that would work out.

Probably the right solution to this problem is for GDM to save it's socket in /var/run/gdm on systems that support it.  To fix this, add some code to configure.ac like this

--start configure.ac changes--

if test -d /var/run ; then
  SOCKETS_DIR = /var/run/
else
  SOCKETS_DIR = /tmp
fi

AC_SUBST(SOCKETS_DIR)
AC_DEFINE_UNQUOTED(SOCKETS_DIR,"$SOCKETS_DIR")

--end of configure.ac changes--

You probably need to add SOCKETS_DIR to acconfig.h like the others.

Test this by running autoconf and re-running configure.  Make sure that SOCKETS_DIR gets set in config.h properly.

Then modify daemon/gdm.h like this:

#define GDM_SUP_SOCKET "/tmp/.gdm_socket"

becomes

#define GDM_SUP_SOCKET SOCKETS_DIR"/.gdm_socket"

Recompile, restart gdm (run gdm-restart), and test as follows:

Make sure that it puts the socket file in /var/run/gdm instead of in /tmp and has the same permissions it used to have in /tmp. 

Change your GDM configuration so the GUI has a different theme or logo or something make sure this works.  Make sure the following command returns the right location of the file:

  gdmflexiserver --command="GET_CONFIG daemon/PidFile"

Let me know if this helps.

Brian do you know if Solaris supports abstracts sockets?  If so, that might be another option.

Lowering this bug to minor priority since the crash is really caused by the user running a tool that deletes the sockets file in /tmp.  Not sure GDM really needs to support such usage.  However it might be good to move the sockets file somewhere else, so leaving this as an enhancement request.

I think it might also mean that anyone can create /tmp/.gdm_socket and prevent gdm from starting.

What happens if /tmp/.gdm_socket is a symlink pointing to /etc/passwd?

There's also a FHS compliance issue here.

I'd be happy to accept a patch to move this file into a different directory, perhaps to /tmp/gdm

Created attachment 87860 [details] [review]
Move the socket to /var/run

I think /var/run is a better place than /tmp; /tmp/gdm/something would probably suffer from the same problems as /tmp.  (Attaching the patch we're using.)

One problem with changing this is that all programs that currently call the socket directly will need to change at the same time.  I believe gnome-panel and FUSA both do this.

I think we probably need to get buy-in from them and also provide patches so that these programs check first in /var/run for the socket file, and then in /tmp (for backwards compatibility).  

Do you want to do this?

Yeah, Sébastien mentionned this to me, and I forgot to mention here.

I think I'll file bugs against panel and fusa (anything else?) blocking this bug and requesting implementation of fallback socket.

I believe only the panel and fusa would need to change to accomodate this.
When you file the bugs, make sure that they are referenced in this bug as dependencies.

FUSA has been fixed already.  This was tracked in bug 408309, but it was reopened because of code cosmetics, so I'm not adding it to the list of dependencies.

gnome-session also needs a patch :-)

I've also fixed gnome-session.
Would it be possible to file bugs so that we remove the fallback use of /tmp/.gdm_socket in a future release?

Okay, so does this mean that all sockets have been fixed in gnome-session, gnome-panel, and fusa?  If so, then I think we can go ahead and put this into GDM.  I'll put this into GDM 2.19.2 just to give the other modules a bit more time to let their changes soak.

Now that 2.19.1 is out the door, I went ahead and put this change in SVN head so it will go into 2.19.2.