gdm upstart script fails to start gdm

Scott could you have a look to this one?

Seb: You probably know better than me how to debug why gdm won't start

Pete has logs that make it look like Upstart started it ok, and them gdm crashed?

I have similar behaviour from my gdm. It starts X, somehow thinks it should be killed (or something dies?) right after it started and tries again. It doesn't even start a greeter (like in Pete's case), although upstart does claim gdm is actually started.

I've also attached my gdm logs, although I'm not sure whether its the same issue or something related that should actually be reported separately.

the title suggested it was an upstart script issue but it might not, can you start xorg without using gdm but by running startx directly? do you get any crash in /var/crash?

I have same problem in gdm on amd64.

@Seb - Yes, I can start x with startx and I can start gdm as root with `sudo /usr/sbin/gdm`. How can I show you the console log during bootup? I tried dmesg, but that doesn't show it. I surmised that it was upstart because gdm can be started manually as can X. Let me know what other information I can give you.

not sure what would be useful there, how is it failing exactly? could you add the /var/log/syslog message Xorg.0.log on a broken boot and the gdm logs too?

Attaching the logs from when I had just booted. I am always left at a command prompt at this point.

Don't know how I didn't see this before, but the constant re-spawning of gdm is logged in syslog. Unfortunately, there isn't much information on _why_ gdm was failing.

Thought the following gdm log might help.

I'm not sure what is going on there, could start without gdm and try running start or gdm by hand and see how it works?

I already stated in two other comments that starting gdm manually works just fine. :-) In fact that is the only reason my netbook is still usable. Basically I am always left at a command prompt when I first boot. I login then run `sudo /usr/sbin/gdm` and I'm up and running. While this is a blessing for now and allows me to continue working, I cannot keep doing this. I just want to find out why gdm no longer starts. Any troubleshooting steps you can give me would be much appreciated.

Btw, if you feel this is an isolated incident and not wide spread I'm happy to re-install and hope it doesn't happen again. I just wanted to be sure this wasn't a) widespread or b) indicative of a larger issue.

you seem to be the only one to have the issue so far but it doesn't mean that there is not an issue there, would be nice to get that sorted rather than doing a reinstall, I've no clue about upstart though to debug this one, I will see if I can get somebody else to comment

Hi there,

For anyone with this gdm problem, does "start gdm" work when you eventually reach the command prompt? If so, the upstart is ok and your gdm start point may be out of sequence compared to the pre-upstart configuration.

I have had this problem on my eepc and have been following these messages with interest. I have just identified a solution to my problem that may help. I mount my /var/log.. etc as tmpfs to protect the solid state drive and gdm refuses to start until certain directories are recreated. I had a set of mkdir commands in rc.local that were correctly sequenced before gdm moved to upstart.

However, gdm has now moved to upstart, it has probably altered the sequence that my rc.local is called in to create the directories, hence the gdm never actually appeared because the script ran before my directories were created. When I reached the command prompt, start gdm worked identifying that the sequence was wrong, not the upstart script. I have created a new file /etc/init/rc_local.conf and filled it with those mkdir commands and copied start tests from the /etc/init/gdm.conf. In order to satisfy the correct sequencing, I also added a test "start on started rc_local" to the gdm.conf and this cured the problem - boots straight to gdm again.

My problem is probably a transient due to the dev state of karmic, because the initscripts are half managed by two separate programs. I am not a developer, but perhaps reading this might help you find the cause of your own issue. No problems on my other machines with basic init configurations.
Cheers
GR

Same here.

"Start GDM" only tells me that GDM is already running. "restart gdm" works and brings me to the login screen. But I only tried that once on tty2 (got tty1 to lock up by running "startx") as I only just ran into the bug when booting the system a few minutes ago after yesterday's updates.

@GRMM - I have seen the bug you are reporting and that is not the bug I'm encountering. The /var/log/gdm directory exists and is not mounted any differently.

@Klaus - `sudo restart gdm` has no effect. `sudo start gdm` returns a PID, but does not start gdm. Running `sudo status gdm` immediately afterward says that gdm is "stopped/waiting" when it should return the same PID as the start command.

The only way I can get gdm to start is to use `sudo /usr/sbin/gdm`. I can find no other way to make this work and I cannot figure out why.

@Pete: Hmmm... that's strange. Maybe we run different packages? I guess it's a silly question, but do you run the latest packages available? I just updated an hour ago and the problem is still the same but "sudo start gdm" brings gdm up.

@Klaus - Yes, afaik we have the same packages and I update daily and read many of the change logs to see if any updates will help or give me a clue as to where the problem may be.

I did have a thought. Afaik with Upstart a service can have dependencies, so we start gdm, but gdm depends (for example) so that triggers the X server to start. Looking at the man pages I see that some services may be started such that they can return success without waiting for dependencies. I wonder if one of the dependent upstart processes is failing and therefore gdm is silently failing.

Hey again Scott, could you look to the most recent questions from Pete about upstart and reply to those for us? thanks!

@Pete: That might certainly be the case. I haven't read much about upstart so far but I will have to deepen my research in that area.
But it's interesting to see two machines with the same patch-level and the same problem reacting so differently. Someone mentioned in the karmic-testing-forum he was able to start gdm just by switching to tty7. I haven't tried it as I don't want to reboot in a situation like this unless it's absolutely necessary ;)

Miracle of miracles... it works now. I tried an update and (for reasons totally unrelated) only 8 packages were updated. Apparently one of them fixed things because now on reboot and cold boot gdm starts of it's own volition.

/me breathes a sigh of relief

Some of the written symptoms here makes me notice a resemblance with this bug:
https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/434361

I always get tty1 and usplash, turning to tty7 will load xsplash, gdm and x.

An addition to my post above.
After I hit ctrl+alt+F7 (tty7) and gdm + x started, a system crash report appeared, informing of a serious kernel issue and suggesting a restart.
Today I reinstalled all the latest kernel packages (2.6.31-10).
Now the systems works as it should. Karmic opens: grub - xsplash-gdm-xsplash-x.

After the latest sets of updates my machine booted up tomorrow morning in a matter of seconds and directly into GDM. I'm a happy chappy now :)

Oh my, I guess I was a bit too excited - that should read "this" and not "tomorrow"^^ Even I am not gifted with the ability to see the future :D

I guess this bug affects my system too. See attachements.

Todays updates fixed the problem.

For me, the bug was caused by booting to single user. /etc/init/gdm.conf wil exit if you booted to single user:

    # Check kernel command-line for inhibitors
    for ARG in $(cat /proc/cmdline)
    do
        case "${ARG}" in
            text|-s|s|S|single)
                exit 0
                ;;
        esac
    done

Could other users confirm it's fixed now?

Doesn't seem like it. Exact same symptoms: 'start gdm' reports a pid, but gdm does not come up. syslog shows that it tried to spawn too many times. sudo gdm does work just fine.

It seems like this is still related to booting into recovery mode and then continuing the boot.

dupe of 436936?

I think the behavior Lupe mentioned is actually a feature. I noticed the same thing while messing around with getting to gdm straight out of single-user mode, which apparently is so fraught with danger that it's forbidden (despite me telinit-ing to runlevel 2 first).

I have the same problem on my IBM Thinkpad T23. But it only happens with _some_ kernels. For instance, I can repro the bevaviour with the new 2.6.33 kernel. 2.6.23.7 works (i.e. the boot process doesn't end with the command prompt and I do not need to start gdm manually ), but only with this additional line in rc.local:

/etc/init.d/gdm restart

I haven't seen this bevaviour with previous Ubuntu versions. But in Karmic, both gdm and upstart have changed... as far as I am concerned these changes have been introduced too quickly and need more testing (not only because of this anomaly, there other additional ones, e.g. the mount of my NFS network drive fails during boot).

Stefan

In my previous post, I meant "2.6.32.7", not "2.6.23.7", sorry...

Stefan

Thank you for taking the time to report this bug and helping to make Ubuntu better. A new version of GDM is available in both Lucid and Maverick and we are wondering if this is still reproducible in any of those versions, May you please test and give us of feedback about it? Thanks in advance.

Seems like it is fixed in Lucid.