First attempt to login on gdm fails

This is a snippet of my /var/log/syslog file wich contains some useful info.

Hmmmm... I guess you can ignore my lines from Xorg.0.log. This logfile is from 18:45, while my syslog lines are from 19:47. The last time I was using Xgl which writes it's logs to /var/log/Xorg.93.log

BWT:
The lines in syslog appear during my login attempt.
This issue occures while using Xgl and normal Xorg.
I have tested this with various user accounts.

Unfortunately/fortunately since I reinstalled dapper this issue has been resolved for me. But just as a confirmation, this used to happen regularly.

It's not thta long ago that I reinstalled my entire system. I installed from the Kubuntu Flight 4 CD, and dist-upgraded from there.

I tried to reinstall gdm (apt-get --purge remove gdm; apt-get install gdm), but that doensn't help.
Seems like this is not in gdm at all, but perhaps gdm is started to soon in the startup process.
If I login to tty1 and restart gdm from there, everithing works fine.

I had a similar problem before, when my NFS filesystems could not be mounted and my NIS client couldn't connect to the server, because the startup scripts were started before I got an IP address from de DHCP server.

Thanks for your bug. Do you have a /etc/gdm/gdm.conf configuration? Is it accessible by gdm? Do you have something specific to your configuration (you speak about NFS and NIS by example)?

Yes I have a /etc/gdm/gdm.conf configuration file with the following permissions: -rw-r--r-- 1 root root
This is the default, because of my reinstall of gdm (see above) all configuration files were deleted and the default files from the package were installed again.

I use NIS and NSF as a client. Those work fine now.
I also installed courier-imap and postfix to migrate some mail, but those are uninstalled now.

As I mentioned before, I installed my system using a Kubuntu CD. So I have also kdm installed. Somthing I noticed was the different starting order of gdm and kdm:
/etc/rc2.d/S13gdm
/etc/rc2.d/S99kdm

When I rename S13gdm to S99gdm, I never see the default Ubuntu theme, but the circles theme is loaded. It works now, but whithin gnome, I cannot restart/shutdown my machine. To do that, I must logout first.

Sorry for the double post: I refreshed my browser window...

I found out that the lines in syslog are most likely to be produced by gdmsetup:

[terminal output]
root@neo:~# gdmsetup
  Failed to connect to socket, sleep 1 second and retry
  Trying failed command again. Try 2 of 5.
  Failed to connect to socket, sleep 1 second and retry
  Trying failed command again. Try 3 of 5.
  Failed to connect to socket, sleep 1 second and retry
  Trying failed command again. Try 4 of 5.
  Failed to connect to socket, sleep 1 second and retry
  Trying failed command again. Try 5 of 5.
  Command failed 5 times, aborting.
Kon het configuratiebestand van GDM niet benaderen.
root@neo:~#
[/terminal output]

The last line is dutch and means as much as: Could not approach (find?) the GDM configuration file.
Still all permissions are setup right. I even tried to give the gdm group write access to the configuration files, but that also didn't work.

The original translation is: "Could not access GDM configuration file."

The strangest thing about this is still that if I restart gdm manually everything works fine.
Anyone knows where this 'socket' is located?

I've no real idea on your issue but reopening the bug since you provided details and somebody else might have some idea on it. Note that you would probably get a better reply on bugzilla.gnome for it, upstream knows the code and is usually responsive and try to get issues sorted. Do you think you could forward that issue upstream?

Thank you for your efforts.

I made a report for this on bugzilla.gnome.org:
http://bugzilla.gnome.org/show_bug.cgi?id=343091

If anything usefull comes out, I will update this report.

Marking as confirmed since it's forwarded upstream; I've subscribed to the bug so I'll notice changes on it, thank you for forwarding it

I removed gdm from my default startup procedure, and started it by hand. Now
everything was fine.

This tells me that this issue is not an issue of gdm, but more an issue of how
my machine boots up and the state my machine is in at the time gdm is started.

What do you think Sebastien?

I'm not sure of what could create that situation, let's wait if upstream has an idea on the topic

As I mentioned in the upstream bugreport:

I removed gdm from my default startup procedure, and started it by hand. Now
everything was fine.

This tells me that this issue is not an issue of gdm, but more an issue of how
my machine boots up and the state my machine is in at the time gdm is started.

Upstream closed the bug with reason 'NOTABUG'. I asked them If they had any idea of what could create this situation.

Does anybody out here have an idea about this?

No idea on my part, not easy to comment on a bug you don't get ...

Hmmm... perhaps I should just wait until my Ubuntu 6.06 LTS cd's arrive from shipit, and do a clean install, like Brendan said.

Thanks for all your input anyway!

Or perhaps I shouldn't wait... ;-)
I think I'm getting closer to the answer here:

I was playing a bit with the startup order of the scripts and I found out: if I remove '/etc/rc2.d/S98mountnfs' everthing works fine.

My nfs filesystem is mounted anyway (I gave it the auto option).

Also, I think a reinstall would eventually leave me with the same problem, because I will configure my system as it is now...

Isn't the /etc/init.d/mountnfs script a bit superfluous anyway?
Because my nfs filesystem is mounted automatically (by specifying 'auto' in /etc/fstab)

Also portmap is also started by the portmap script way before the mountnfs script is started.

We have never shipped an etc2.d/S98mountnfs script -- this sounds very much like you have customised your boot process and broken it

I have to admit that you could be right Scott.
Earlier in this bugreport I mentioned that my nfs filesystem wasn't mounted in the boot process, because my network wasn't fully configured yet at that time in de boot process.

Because of that it seems to be a logical decision to make a symlink from /etc/init.d/mountnfs.sh to /etc/rc2.d at the end of the boot process. I guess I might have did just that.
The boot process worked perfectly fine until just recently, by the way.

I'm sorry to have bothered you with this false bugreport.

I have the same issue!

any news??

Since I removed the symlink /etc/rc2.d/S98mountnfs, pointing to /etc/init.d/mountnfs.sh. This issue is resolved for me.

As I mentioned earlier, I have created that symlink myself. Perhaps you're dealing with a different issue. Please describe what you're experiencing, perhaps in a new bugreport.